В разработке программного обеспечения гибкие методы (иногда называемые « Agile ») [1] включают в себя совершенствование требований, обнаружение и решение посредством совместных усилий самоорганизующихся и кросс-функциональных команд со своими клиентами / конечными пользователями . [2] [3] Эти ценности и принципы, популяризированные в «Манифесте гибкой разработки программного обеспечения» 2001 года , [4] были получены и лежат в основе широкого спектра сред разработки программного обеспечения , включая Scrum и Kanban . [5] [6]
Несмотря на то, что существует множество неофициальных свидетельств того, что внедрение гибких практик и ценностей повышает эффективность специалистов, команд и организаций в области программного обеспечения, эмпирические данные неоднозначны, и их трудно найти. [7] [8] [9]
Итеративные и инкрементные методы разработки программного обеспечения можно проследить еще в 1957 году, [10] с эволюционным управлением проектами [11] [12] и адаптивной разработкой программного обеспечения [13] , появившимися в начале 1970-х годов. [14]
В течение 1990-х годов ряд облегченных методов разработки программного обеспечения развился как реакция на преобладающие тяжеловесные методы (часто называемые «водопадными» ) , которые критики описывали как чрезмерно регулируемые, планируемые и микроуправляемые . [15] Эти облегченные методы включали: быструю разработку приложений (RAD), с 1991 года; [16] [17] единый процесс (UP) и метод разработки динамических систем (DSDM), оба с 1994 года; Скрам , с 1995 года; Crystal Clear и экстремальное программирование (XP), оба с 1996 года; и разработка на основе функций (FDD) с 1997 года. Хотя все они возникли до публикации Agile Manifesto , теперь их все вместе называют гибкими методами разработки программного обеспечения. [6]
Уже с 1991 года подобные изменения происходили в производстве [18] [19] и управленческом мышлении [20] , основанном на бережливом управлении .
В 2001 году семнадцать разработчиков программного обеспечения встретились на курорте в Сноуберде , штат Юта , чтобы обсудить облегченные методы разработки. Это были: Кент Бек (экстремальное программирование), Уорд Каннингем (экстремальное программирование), Дэйв Томас ( PragProg , Ruby), Джефф Сазерленд (Scrum), Кен Швабер (Scrum), Джим Хайсмит (разработка адаптивного программного обеспечения), Алистер Кокберн (Crystal). , Роберт К. Мартин ( SOLID ), Майк Бидл (Scrum), Ари ван Беннекум, Мартин Фаулер ( OOAD и UML ), Джеймс Греннинг, Эндрю Хант (PragProg, Ruby), Рон Джеффрис (экстремальное программирование), Джон Керн, Брайан Марик (Рубин, TDD ) и Стив Меллор ( OOA ). Вместе они опубликовали Манифест гибкой разработки программного обеспечения . [4]
В 2005 году группа, возглавляемая Кокберном и Хайсмитом, написала дополнение к принципам управления проектами , «Декларацию взаимозависимости PM», [21] , чтобы направлять управление проектами программного обеспечения в соответствии с гибкими методами разработки программного обеспечения.
В 2009 году группа, работающая с Мартином, написала расширение принципов разработки программного обеспечения , «Манифест мастерства программного обеспечения» , чтобы направлять гибкую разработку программного обеспечения в соответствии с профессиональным поведением и мастерством.
В 2011 году Agile Alliance создал « Руководство по гибким практикам» (переименованное в « Глоссарий Agile» в 2016 году), [22] развивающийся сборник с открытым исходным кодом рабочих определений, терминов и элементов гибких методов, а также интерпретаций и руководств по опыту от мировое сообщество практиков agile.
Основываясь на своем совместном опыте разработки программного обеспечения и помощи другим в этом, авторы манифеста заявили, что они ценят: [4]
То есть, хотя обе стороны имеют ценность и следует учитывать пункты справа, авторы считают, что пункты слева должны иметь большее влияние на то, как люди подходят к своей работе.
Как объяснил Скотт Эмблер : [23]
Некоторые из авторов сформировали Agile Alliance, некоммерческую организацию, которая продвигает разработку программного обеспечения в соответствии с ценностями и принципами манифеста. Представляя манифест от имени Agile Alliance, Джим Хайсмит сказал:
Движение Agile не является антиметодологией, на самом деле многие из нас хотят восстановить доверие к слову «методология». Мы хотим восстановить баланс. Мы занимаемся моделированием, но не для того, чтобы закинуть какую-то диаграмму в пыльный корпоративный репозиторий. Мы принимаем документацию, а не сотни страниц никогда не поддерживаемых и редко используемых томов. Мы планируем, но осознаем пределы планирования в турбулентной среде. Те, кто называет сторонников XP, SCRUM или любой другой гибкой методологии «хакерами», не знают ни самих методологий, ни исходного определения термина «хакер».
- Джим Хайсмит, История: Манифест Agile [24]
Манифест гибкой разработки программного обеспечения основан на двенадцати принципах: [25]
Большинство методов гибкой разработки разбивают работу по разработке продукта на небольшие этапы, которые минимизируют объем предварительного планирования и проектирования. Итерации, или спринты, представляют собой короткие временные рамки ( таймбоксы ) [26] , которые обычно длятся от одной до четырех недель. [27] : 20 В каждой итерации участвует межфункциональная команда , выполняющая все функции: планирование , анализ , проектирование , кодирование , модульное тестирование и приемочное тестирование . В конце итерации заинтересованным сторонам демонстрируется работающий продукт. Это сводит к минимуму общий риск и позволяет продукту быстро адаптироваться к изменениям. [28] [29] Итерация может не добавить достаточной функциональности, чтобы гарантировать выпуск на рынок, но цель состоит в том, чтобы иметь доступный выпуск (с минимальным количеством ошибок ) в конце каждой итерации. [30] Благодаря поэтапной разработке продукты могут « часто и рано выходить из строя » на каждом итерационном этапе, а не резко в день окончательного выпуска. [31] Для выпуска продукта или новых функций может потребоваться несколько итераций. Работающее программное обеспечение является основным показателем прогресса. [25]
Ключевым преимуществом гибких подходов является скорость выхода на рынок и снижение рисков. На рынок обычно выводятся меньшие приращения, что снижает временные и финансовые риски, связанные с разработкой продукта, который не соответствует требованиям пользователя.
Шестой принцип гибкого манифеста разработки программного обеспечения гласит: «Самый эффективный и действенный метод передачи информации внутри команды разработчиков — это личное общение». В манифесте, написанном в 2001 году, когда видеоконференции еще не получили широкого распространения, говорится, что в отношении передачи информации не обязательно размещать команды в одном месте.
Принцип совместного размещения заключается в том, что сотрудники одной команды должны располагаться вместе, чтобы лучше укрепить идентичность команды и улучшить общение. [32] Это обеспечивает личное взаимодействие , в идеале перед доской, что сокращает время цикла, которое обычно занимает, когда вопросы и ответы передаются через телефон, постоянный чат , Wiki или электронную почту. [33] С широким распространением удаленной работы во время пандемии COVID-19 и изменениями в инструментах было проведено больше исследований [34] по вопросам совместного размещения и распределенной работы, которые показывают, что совместное размещение становится все менее актуальным.
Независимо от того, какой метод разработки используется, в каждой команде должен быть представитель заказчика ( в Scrum он называется владельцем продукта ). Заинтересованные стороны соглашаются, что этот представитель будет действовать от их имени, и он берет на себя личное обязательство быть доступным для разработчиков, чтобы отвечать на вопросы на протяжении всей итерации. В конце каждой итерации участники проекта вместе с представителем заказчика анализируют ход выполнения и переоценивают приоритеты с целью оптимизации окупаемости инвестиций (ROI) и обеспечения соответствия потребностям заказчика и целям компании. Важность удовлетворения заинтересованных сторон, детализируемая посредством частого взаимодействия и анализа в конце каждого этапа, является причиной того, что этот подход часто называют методологией, ориентированной на клиента . [35]
В гибкой разработке программного обеспечения информационный радиатор представляет собой (обычно большой) физический дисплей, доску с стикерами или что-то подобное, расположенный на видном месте рядом с командой разработчиков, где его могут видеть прохожие. [36] В нем представлена актуальная сводка состояния разработки продукта. [37] [38] Световой индикатор сборки также можно использовать для информирования команды о текущем состоянии разработки продукта.
Общей характеристикой гибкой разработки программного обеспечения является ежедневный стендап (известный как ежедневный Scrum в рамках Scrum). В ходе короткого занятия (например, 15 минут) члены команды коллективно анализируют, как они продвигаются к своей цели, и соглашаются, нужно ли им адаптировать свой подход. Чтобы соблюсти согласованный лимит времени, команды часто используют простые закодированные вопросы (например, что они выполнили накануне, что они планируют выполнить в этот день, есть ли какие-либо препятствия или риски для прогресса) и откладывают детальное обсуждение и решение проблем. решение до окончания стендапа. [39]
Конкретные инструменты и методы, такие как непрерывная интеграция , автоматизированное модульное тестирование , парное программирование , разработка через тестирование , шаблоны проектирования , разработка на основе поведения , проектирование на основе предметной области , рефакторинг кода и другие методы, часто используются для повышения качества и улучшения разработки продуктов. ловкость. [40] Это основано на качественном проектировании и создании с самого начала и возможности демонстрировать программное обеспечение клиентам в любой момент или, по крайней мере, в конце каждой итерации. [41]
По сравнению с традиционной разработкой программного обеспечения, гибкая разработка программного обеспечения в основном нацелена на разработку сложных систем и продуктов с динамическими, недетерминированными и нелинейными свойствами . Точные оценки, стабильные планы и прогнозы зачастую трудно получить на ранних стадиях, и доверие к ним, скорее всего, будет низким. Практикующие Agile используют свою свободную волю , чтобы уменьшить « скачок веры », который необходим, прежде чем можно будет получить какие - либо доказательства ценности . [42] Требования и проектирование считаются возникающими . В таких случаях большие предварительные спецификации, вероятно, приведут к большим потерям, т. е. будут экономически нецелесообразными. Эти основные аргументы и предыдущий отраслевой опыт , извлеченный из многих лет успехов и неудач, помогли сформировать в гибкой разработке предпочтение адаптивной, итеративной и эволюционной разработки. [43]
Существуют различные методы разработки: от адаптивных до прогнозирующих . [44] Гибкие методы разработки программного обеспечения лежат на адаптивной стороне этого континуума. Одним из ключевых методов адаптивной разработки является подход к планированию графика на основе катящейся волны , который определяет вехи, но оставляет гибкость в пути их достижения, а также позволяет изменять сами вехи. [45]
Адаптивные методы направлены на быструю адаптацию к меняющимся реалиям. Когда потребности проекта меняются, меняется и адаптивная команда. Адаптивная команда испытывает трудности с точным описанием того, что произойдет в будущем. Чем дальше дата, тем более расплывчатым является адаптивный метод относительно того, что произойдет в эту дату. Адаптивная команда не может точно сообщить, какие задачи они будут выполнять на следующей неделе, а только то, какие функции они планируют реализовать в следующем месяце. Когда адаптивную команду спросят о выпуске через шесть месяцев, она сможет сообщить только формулировку миссии релиза или заявление об ожидаемой ценности и стоимости.
Прогностические методы, напротив, фокусируются на детальном анализе и планировании будущего и учитывают известные риски. В крайнем случае, команда прогнозистов может точно сообщить, какие функции и задачи запланированы на протяжении всего процесса разработки. Прогнозные методы основаны на эффективном анализе на ранней стадии, и если что-то пойдет не так, проекту может быть трудно изменить направление. Команды прогнозирования часто создают совет по контролю изменений , чтобы гарантировать, что они рассматривают только наиболее ценные изменения.
Анализ рисков можно использовать для выбора между адаптивными ( гибкими или ориентированными на ценность ) и прогнозирующими ( ориентированными на план ) методами. [46] Барри Бём и Ричард Тёрнер предполагают, что каждая сторона континуума имеет свою собственную родину , а именно: [47]
Одним из отличий гибких методов разработки программного обеспечения от каскадных является подход к качеству и тестированию. В каскадной модели работа проходит через этапы жизненного цикла разработки программного обеспечения (SDLC) — причем один этап завершается до начала другого, поэтому этап тестирования является отдельным и следует за этапом сборки . Однако при гибкой разработке программного обеспечения тестирование завершается на той же итерации, что и программирование.
Поскольку тестирование проводится на каждой итерации, при которой разрабатывается небольшая часть программного обеспечения, пользователи могут часто использовать эти новые части программного обеспечения и проверять их ценность. После того, как пользователи узнают реальную ценность обновленной части программного обеспечения, они смогут принять более обоснованные решения относительно будущего программного обеспечения. Проведение ретроспективы ценности и сеанса перепланирования программного обеспечения на каждой итерации (в Scrum обычно итерации длятся всего две недели) помогает команде постоянно корректировать свои планы, чтобы максимизировать приносимую ими ценность. Это следует шаблону, аналогичному циклу «планируй-делай-проверяй-действуй» (PDCA), поскольку работа планируется , выполняется , проверяется (в обзоре и ретроспективе), и любые согласованные изменения принимаются в действие.
Этот итеративный подход поддерживает продукт , а не проектное мышление. Это обеспечивает большую гибкость на протяжении всего процесса разработки; тогда как в проектах требования определены и зафиксированы с самого начала, что затрудняет их дальнейшее изменение. Итеративная разработка продукта позволяет программному обеспечению развиваться в ответ на изменения в бизнес-среде или требованиях рынка.
В письме в IEEE Computer Стивен Ракитин выразил цинизм по поводу гибкой разработки программного обеспечения, назвав это « еще одной попыткой подорвать дисциплину разработки программного обеспечения » и переведя « работающее программное обеспечение вместо всеобъемлющей документации », поскольку « мы хотим тратить все свое время на программирование». Помните, настоящие программисты не пишут документацию ». [48]
Это оспаривается сторонниками гибкой разработки программного обеспечения, которые заявляют, что разработчики должны писать документацию, если это лучший способ достижения соответствующих целей, но часто существуют лучшие способы достижения этих целей, чем написание статической документации. [49] Скотт Эмблер утверждает, что документация должна быть «достаточно хорошей» (JBGE), [50] что слишком большая или исчерпывающая документация обычно приводит к ненужным тратам, а разработчики редко доверяют подробной документации, потому что она обычно не синхронизирована с кодом, [ 49] , в то время как слишком мало документации может также вызвать проблемы с обслуживанием, общением, обучением и обменом знаниями. Алистер Кокберн писал о методе Crystal Clear :
Кристал рассматривает разработку серии кооперативных игр и предполагает, что документации будет достаточно, чтобы помочь в следующей победе в следующей игре. Рабочие продукты для Crystal включают варианты использования, список рисков, план итераций, основные модели предметной области и примечания к проектированию, информирующие о выборе... однако для этих документов нет шаблонов, и описания обязательно расплывчаты, но цель ясна, просто документации достаточно для следующей игры. Я всегда склонен охарактеризовать это для своей команды так: что бы вы хотели знать, если бы присоединились к команде завтра.
- Алистер Кокберн [51]
Гибкие методы разработки программного обеспечения поддерживают широкий спектр жизненного цикла разработки программного обеспечения . [52] Некоторые методы сосредоточены на практиках (например, XP , прагматическое программирование , гибкое моделирование), тогда как некоторые сосредоточены на управлении потоком работы (например, Scrum, Kanban). Некоторые поддерживают деятельность по спецификации и разработке требований (например, FDD ), тогда как некоторые стремятся охватить полный жизненный цикл разработки (например, DSDM , RUP ).
Известные гибкие среды разработки программного обеспечения включают:
Гибкая разработка программного обеспечения поддерживается рядом конкретных практик, охватывающих такие области, как требования, проектирование, моделирование, кодирование, тестирование, планирование, управление рисками, процесс, качество и т. д. Некоторые известные гибкие практики разработки программного обеспечения включают: [ 53]
В литературе к понятию адаптации метода относятся разные термины, в том числе «адаптация метода», «адаптация фрагмента метода» и «инжиниринг ситуационного метода». Адаптация метода определяется как:
Процесс или способность, в которой агенты-люди определяют подход к разработке системы для конкретной проектной ситуации посредством оперативных изменений и динамического взаимодействия между контекстами, намерениями и фрагментами методов.
- Мехмет Нафиз Айдин и др., Используемый метод разработки гибких информационных систем [66]
Соответствие ситуации следует рассматривать как отличительную характеристику между гибкими методами и более плановыми методами разработки программного обеспечения, при этом гибкие методы позволяют группам разработчиков продуктов адаптировать рабочие методы в соответствии с потребностями отдельных продуктов. [67] [66] Потенциально для адаптации метода могут подойти большинство гибких методов, [52] таких как DSDM , адаптированный в контексте CMM . [68] и XP, адаптированные с использованием методики описания правил (RDP). [69] Однако не все сторонники agile согласны со Швабером, который отмечает, что «именно поэтому мы изначально и попали в беду, думая, что проблема заключалась в отсутствии идеальной методологии. Усилия [должны] быть сосредоточены на изменениях, [необходимых] в предприятие". [70] Бас Водде подкрепил эту точку зрения, предположив, что в отличие от традиционных больших методологий, которые требуют от вас выбора элементов, Scrum предоставляет основы, поверх которых вы добавляете дополнительные элементы для локализации и контекстуализации его использования. [71] Практики редко используют методы разработки систем или, в частности, гибкие методы, согласно книге, часто предпочитая опустить или адаптировать некоторые практики метода, чтобы создать собственный метод. [72]
На практике методы можно адаптировать с помощью различных инструментов. Универсальные языки моделирования процессов, такие как Unified Modeling Language, можно использовать для адаптации методов разработки программного обеспечения. Однако также существуют специальные инструменты для разработки методов, такие как Essence Theory of Software Engineering SEMAT . [73]
Гибкая разработка программного обеспечения широко рассматривается как наиболее подходящая для определенных типов сред, включая небольшие группы экспертов, работающих над новыми проектами , [47] [74] , а также проблемы и ограничения, возникающие при внедрении гибких методов разработки программного обеспечения в крупной организации. с устаревшей инфраструктурой хорошо документированы и понятны. [75]
В ответ был разработан ряд стратегий и моделей для преодоления проблем с помощью крупномасштабных усилий по разработке (>20 разработчиков) [76] [77] или распределенных (несовмещенных) групп разработчиков, [78] [79] среди других проблем. ; и в настоящее время существует несколько признанных рамок, которые стремятся смягчить или избежать этих проблем.
Существует множество противоречивых точек зрения на то, эффективны ли все эти подходы или действительно ли они соответствуют определению гибкой разработки, и этот вопрос остается активной и постоянной областью исследований. [76] [80]
Когда гибкая разработка программного обеспечения применяется в распределенной среде (когда команды рассредоточены по нескольким офисам), ее обычно называют распределенной гибкой разработкой программного обеспечения . Цель состоит в том, чтобы максимально использовать уникальные преимущества, предлагаемые каждым подходом. Распределенная разработка позволяет организациям создавать программное обеспечение, стратегически создавая команды в разных частях земного шара, создавая программное обеспечение практически круглосуточно (чаще называемая моделью «следующего за солнцем»). С другой стороны, гибкая разработка обеспечивает повышенную прозрачность, постоянную обратную связь и большую гибкость при реагировании на изменения.
Гибкие методы разработки программного обеспечения изначально считались наиболее подходящими для разработки некритических продуктов, поэтому их исключали из использования в регулируемых областях, таких как медицинское оборудование , фармацевтика, финансы, ядерные системы, автомобилестроение, авионика и т. д. Однако в последние несколько В течение многих лет было предпринято несколько инициатив по адаптации гибких методов для этих областей. [81] [82] [83] [84] [85]
Существует множество стандартов, которые могут применяться в регулируемых областях, включая ISO 26262 , ISO 9000 , ISO 9001 и ISO/IEC 15504 . Ряд ключевых проблем имеет особое значение в регулируемых сферах: [86]
Хотя на практике методы гибкой разработки программного обеспечения можно использовать с любой парадигмой программирования или языком, изначально они были тесно связаны с объектно-ориентированными средами, такими как Smalltalk, Lisp, а затем с Java, C#. Первыми, кто применял гибкие методы, обычно были небольшие и средние команды, работавшие над беспрецедентными системами с требованиями, которые было трудно доработать и которые могли измениться по мере разработки системы. В этом разделе описаны общие проблемы, с которыми сталкиваются организации, когда пытаются внедрить гибкие методы разработки программного обеспечения, а также различные методы измерения качества и производительности гибких команд. [87]
Индекс измерения гибкости , среди прочего, оценивает разработки по пяти измерениям разработки продукта (продолжительность, риск, новизна, усилия и взаимодействие). [88] Другие методы основаны на измеримых целях [89] , а одно исследование предполагает, что скорость можно использовать как показатель ловкости. Существуют также гибкие методы самооценки, позволяющие определить, использует ли команда гибкие методы разработки программного обеспечения (тест Nokia, [90] тест Карлскруны, [91] тест на 42 балла). [92]
Одним из первых исследований, сообщающих о повышении качества, производительности и удовлетворенности бизнеса за счет использования гибких методов разработки программного обеспечения, было исследование, проведенное Shine Technologies с ноября 2002 года по январь 2003 года. [93]
Аналогичный опрос State of Agile проводится каждый год, начиная с 2006 года, с участием тысяч участников со всего сообщества разработчиков программного обеспечения. Это отслеживает тенденции в отношении предполагаемых преимуществ гибкости, извлеченных уроков и передовой практики. В каждом опросе сообщается о росте числа людей, утверждающих, что гибкая разработка программного обеспечения помогает им быстрее доставлять программное обеспечение; улучшает их способность управлять меняющимися приоритетами клиентов; и повышает их продуктивность. [94] Опросы также неизменно показывают лучшие результаты при использовании гибких методов разработки продуктов по сравнению с классическим управлением проектами. [95] [96] В целом, есть сообщения о том, что некоторые считают, что методы гибкой разработки еще слишком молоды, чтобы проводить обширные академические исследования их успеха. [97]
Организации и команды, реализующие гибкую разработку программного обеспечения, часто сталкиваются с трудностями при переходе от более традиционных методов, таких как каскадная разработка , например, когда командам навязывают гибкий процесс. [98] Их часто называют подвижными антипаттернами или, чаще, подвижными запахами . Ниже приведены некоторые распространенные примеры:
Цель гибкой разработки программного обеспечения — больше сосредоточиться на создании работающего программного обеспечения, а не на документации. В этом отличие от каскадных моделей, где процесс часто строго контролируется, а незначительные изменения в системе требуют значительного пересмотра сопроводительной документации. Однако это не оправдывает полного отказа от какого-либо анализа или проектирования. Неспособность уделить внимание дизайну может привести к тому, что команда сначала будет действовать быстро, но затем потребуется значительная доработка при попытке масштабирования системы. Одной из ключевых особенностей гибкой разработки программного обеспечения является то, что она является итеративной. Если все сделано правильно, гибкая разработка программного обеспечения позволяет проекту проявляться по мере разработки системы и помогает команде обнаружить общие черты и возможности для повторного использования. [99]
При гибкой разработке программного обеспечения истории (похожие на описания вариантов использования ) обычно используются для определения требований, а итерация — это короткий период времени, в течение которого команда ставит перед собой конкретные цели. [100] Добавление историй в текущую итерацию вредит нормальному ходу работы. Их следует добавить в очередь продукта и расставить приоритеты для последующей итерации или, в редких случаях, итерацию можно отменить. [101]
Это не означает, что история не может расширяться. Командам приходится иметь дело с новой информацией, что может привести к появлению дополнительных задач для истории. Если новая информация не позволяет завершить историю во время итерации, то ее следует перенести на следующую итерацию. Однако ей следует отдать приоритет по сравнению со всеми остальными историями, поскольку новая информация могла изменить первоначальный приоритет истории.
Гибкая разработка программного обеспечения часто реализуется в организациях как коллективная работа команд разработчиков программного обеспечения, пытающихся оптимизировать свои процессы разработки и обеспечить согласованность жизненного цикла разработки программного обеспечения. Не имея спонсорской поддержки, команды могут столкнуться с трудностями и сопротивлением со стороны деловых партнеров, других команд разработчиков и руководства. Кроме того, они могут пострадать без надлежащего финансирования и ресурсов. [102] Это увеличивает вероятность неудачи. [103]
Опрос, проведенный VersionOne, показал , что респонденты назвали недостаточное обучение наиболее значимой причиной неудачного внедрения agile [104]. правила гибкой разработки программного обеспечения. [ нужна цитата ]
Владелец продукта отвечает за представление бизнеса в процессе разработки и зачастую является самой ответственной ролью. [105]
Распространенной ошибкой является назначение на роль владельца продукта кого-то из команды разработчиков. Это требует от команды принятия собственных решений по расстановке приоритетов без реальной обратной связи со стороны бизнеса. Они пытаются решать бизнес-проблемы внутри компании или откладывают работу, обращаясь за советом за пределами команды. Это часто приводит к отвлечению внимания и нарушению сотрудничества. [106]
Гибкая разработка программного обеспечения требует от команд выполнения обязательств по продукту, а это означает, что они должны сосредоточиться на работе только над этим продуктом. Однако от членов команды, у которых, как представляется, есть свободные мощности, часто ожидают, что они возьмут на себя другую работу, что затрудняет им выполнение работы, которую взяла на себя их команда. [107]
Команды могут попасть в ловушку, тратя слишком много времени на подготовку или планирование. Это обычная ловушка для команд, менее знакомых с гибкой разработкой программного обеспечения, когда команды чувствуют себя обязанными иметь полное понимание и спецификацию всех историй. Команды должны быть готовы продвигаться вперед только с теми историями, в которых они уверены, а затем во время итерации продолжать обнаруживать и готовить работу для последующих итераций (часто это называется уточнением или очисткой отставания).
Ежедневный стендап должен представлять собой целенаправленную и своевременную встречу, на которой все члены команды распространяют информацию. Если в решении проблемы и происходит, то в нем часто могут участвовать только определенные члены команды, и это потенциально не лучшее использование времени всей команды. Если во время ежедневного стендапа команда начинает погружаться в решение проблем, его следует отложить до тех пор, пока подгруппа не сможет обсудить проблему, обычно сразу после завершения стендапа. [108]
Одним из предполагаемых преимуществ гибкой разработки программного обеспечения является предоставление команде возможности делать выбор, поскольку она ближе всего к проблеме. Кроме того, им следует делать выбор как можно ближе к реализации, чтобы использовать при принятии решения более своевременную информацию. Если членам команды поручают задачи другие или слишком рано в процессе, преимущества локализованного и своевременного принятия решений могут быть потеряны. [109]
Назначение работы также ограничивает членов команды определенными ролями (например, член команды А должен всегда выполнять работу с базой данных), что ограничивает возможности перекрестного обучения. [109] Сами члены команды могут брать на себя задачи, которые расширяют их способности и предоставляют возможности перекрестного обучения.
В рамках Scrum, которая утверждает, что соответствует ценностям и принципам Agile, роль Scrum-мастера отвечает за обеспечение соблюдения процесса Scrum и за обучение Scrum-команды в ходе этого процесса. Распространенной ошибкой является то, что скрам-мастер выступает в роли участника. Хотя это и не запрещено структурой Scrum, Scrum-мастеру необходимо убедиться, что он способен сначала действовать в роли Scrum-мастера, а не работать над задачами разработки. Роль Scrum-мастера — облегчить процесс, а не создать продукт. [110]
Если Scrum-мастер одновременно выполняет несколько задач, это может привести к слишком большому количеству переключений контекста, что не позволит продуктивно работать. Кроме того, поскольку Scrum-мастер отвечает за устранение препятствий, чтобы команда могла продвигаться вперед, выгода, получаемая от продвижения отдельных задач, может не перевешивать препятствия, которые откладываются из-за нехватки возможностей. [111]
Из-за итеративного характера гибкой разработки часто требуется несколько раундов тестирования. Автоматизированное тестирование помогает снизить влияние повторных модульных, интеграционных и регрессионных тестов и позволяет разработчикам и тестировщикам сосредоточиться на более ценной работе. [112]
Автоматизация тестирования также поддерживает постоянный рефакторинг , необходимый для итеративной разработки программного обеспечения. Разрешение разработчику быстро запускать тесты для подтверждения того, что рефакторинг не изменил функциональность приложения, может снизить рабочую нагрузку и повысить уверенность в том, что усилия по очистке не привели к появлению новых дефектов.
Сосредоточение внимания на предоставлении новых функций может привести к увеличению технического долга . Команда должна выделить себе время на исправление дефектов и рефакторинг. Технический долг мешает планированию, увеличивая объем незапланированной работы, поскольку производственные дефекты отвлекают команду от дальнейшего прогресса. [113]
По мере развития системы важно проводить рефакторинг . [114] Со временем отсутствие постоянного обслуживания приводит к увеличению количества дефектов и затрат на разработку. [113]
Распространенным заблуждением является то, что гибкая разработка программного обеспечения допускает непрерывные изменения, однако журнал невыполненных итераций — это соглашение о том, какая работа может быть завершена во время итерации. [115] Слишком большой объем незавершенной работы (НЗП) приводит к неэффективности, такой как переключение контекста и организация очередей. [116] Команда не должна чувствовать давления, требующего выполнения дополнительной работы. [117]
Гибкая разработка программного обеспечения заранее фиксирует время (продолжительность итерации), качество и, в идеале, ресурсы (хотя поддержание фиксированных ресурсов может быть затруднено, если разработчики часто отвлекаются от задач по устранению производственных инцидентов), в то время как объем остается переменным. Заказчик или владелец продукта часто настаивают на фиксированном объеме итерации. Однако командам не следует соглашаться на ограниченное время, ресурсы и объем (широко известный как треугольник управления проектами ). Попытки увеличить объем фиксированного времени и ресурсов гибкой разработки программного обеспечения могут привести к снижению качества. [118]
Из-за целенаправленного темпа и непрерывного характера agile-практик среди членов команды реализации существует повышенный риск выгорания. [119]
Гибкое управление проектами — это итеративный процесс разработки, в ходе которого от пользователей и заинтересованных сторон постоянно собирается обратная связь для создания правильного пользовательского опыта. Для выполнения гибкого процесса можно использовать разные методы, к ним относятся Scrum , экстремальное программирование , Lean и Kanban . [120] Термин «гибкое управление» применяется к итеративному, поэтапному методу управления деятельностью по проектированию и созданию инженерных, информационных технологий и других областей бизнеса, целью которых является обеспечение разработки новых продуктов или услуг очень гибким и интерактивным способом, основанным на принципы, изложенные в Манифесте гибкой разработки программного обеспечения . [121] Метрики гибкого управления проектами помогают уменьшить путаницу, выявить слабые места и измерить производительность команды на протяжении всего цикла разработки. Гибкость цепочки поставок — это способность цепочки поставок справляться с неопределенностью и изменчивостью предложения и спроса. Гибкая цепочка поставок может быстро увеличивать и уменьшать свои мощности, поэтому она может адаптироваться к быстро меняющемуся потребительскому спросу. Наконец, стратегическая гибкость — это способность организации менять свой образ действий по мере развития ее среды. Ключом к стратегической гибкости является достаточно раннее распознавание внешних изменений и распределение ресурсов для адаптации к этим меняющимся условиям. [120]
Методы Agile X можно также назвать экстремальным управлением проектами . Это вариант итеративного жизненного цикла [122] , при котором результаты предоставляются поэтапно. Основное различие между гибкой и итеративной разработкой заключается в том, что гибкие методы завершают небольшие части результатов в каждом цикле поставки (итерации), [123] в то время как итеративные методы развивают весь набор результатов с течением времени, завершая их ближе к концу проекта. И итеративные, и гибкие методы были разработаны как реакция на различные препятствия, возникшие в более последовательных формах организации проекта. Например, по мере усложнения технологических проектов конечным пользователям, как правило, трудно определить долгосрочные требования, не имея возможности просмотреть прогрессивные прототипы. Проекты, разрабатываемые итерациями, могут постоянно собирать отзывы, помогающие уточнить требования.
Гибкое управление также предлагает простую структуру, способствующую общению и размышлению о прошлой работе среди членов команды . [124] Команды, которые использовали традиционное каскадное планирование и приняли гибкий способ разработки, обычно проходят фазу трансформации и часто обращаются за помощью к agile-коучам, которые помогают командам пройти через более плавную трансформацию. Обычно существует два стиля гибкого коучинга: Agile-коучинг, основанный на подталкивании и вытягивании. Здесь «толкающая система» может относиться к предварительной оценке того, какие задачи могут быть включены в спринт (подталкивающая работа), например, типично для Scrum; тогда как «вытягивающая система» может относиться к среде, в которой задачи выполняются только тогда, когда работа доступна, например, что типично для канбана. [ необходимы разъяснения ] Гибкие подходы к управлению также использовались и адаптировались к деловому и государственному секторам. Например, в федеральном правительстве США Агентство США по международному развитию (USAID) использует подход к совместному управлению проектами, который фокусируется на включении стратегий сотрудничества, обучения и адаптации (CLA) для повторения и адаптации программ. [125]
Гибкие методы упоминаются в Руководстве по своду знаний по управлению проектами ( Руководство PMBOK, 6-е издание ) в разделе определения жизненного цикла разработки продукта :
«В рамках жизненного цикла проекта обычно существует одна или несколько фаз, связанных с разработкой продукта, услуги или результата. Они называются жизненным циклом разработки (...). Адаптивные жизненные циклы бывают гибкими, итеративными или Инкрементный. Подробный объем определяется и утверждается перед началом итерации. Адаптивные жизненные циклы также называются гибкими или управляемыми изменениями жизненными циклами. [126]
По словам Жана-Лу Рише (научного сотрудника Института стратегических инноваций и услуг ESSEC ), «этот подход можно эффективно использовать для непрограммных продуктов и для управления проектами в целом, особенно в областях инноваций и неопределенности». Результатом является продукт или проект, который наилучшим образом соответствует текущим потребностям клиентов и поставляется с минимальными затратами, отходами и временем, что позволяет компаниям достичь прибыли раньше, чем при использовании традиционных подходов. [127]
Методы гибкой разработки программного обеспечения широко используются для разработки программных продуктов, и некоторые из них используют определенные характеристики программного обеспечения, такие как объектные технологии . [128] Однако эти методы могут быть применены к разработке непрограммных продуктов, таких как компьютеры, медицинские устройства, продукты питания, одежда и музыка. [129] Гибкие методы разработки программного обеспечения использовались при развертывании и миграции ИТ-инфраструктуры, не связанной с разработкой . Некоторые из более широких принципов гибкой разработки программного обеспечения также нашли применение в общем менеджменте [130] (например, стратегия, управление, риск, финансы) под терминами « гибкость бизнеса » или «гибкое управление бизнесом».
Гибкие парадигмы разработки программного обеспечения можно использовать и в других сферах жизни, например, в воспитании детей. Его успех в развитии детей может быть основан на некоторых основных принципах управления; общение, адаптация и осведомленность. В своем выступлении на TED Брюс Фейлер рассказал, как он применяет базовые agile-парадигмы в ведении домашнего хозяйства и воспитании детей. [131]
Гибкие методы были названы потенциально неэффективными в крупных организациях и определенных типах разработки. [132] Многие организации считают, что гибкие методологии разработки программного обеспечения являются слишком экстремальными, и применяют гибридный подход [133] , который сочетает в себе элементы гибкой разработки программного обеспечения и подходов, основанных на планах. [134] Некоторые методы, такие как метод разработки динамических систем (DSDM), пытаются сделать это дисциплинированно, не жертвуя фундаментальными принципами.
Растущее внедрение гибких практик также подвергается критике как управленческая причуда , которая просто описывает существующие передовые методы на новом жаргоне, продвигает единый , подходящий всем образ мышления в отношении стратегий развития и ошибочно ставит метод выше результатов. [135]
Алистер Кокберн организовал празднование 10-летия Манифеста гибкой разработки программного обеспечения в Сноуберде, штат Юта, 12 февраля 2011 года, собрав около 30+ человек, которые участвовали в первоначальной встрече и после нее. Был собран список из примерно 20 « слонов в комнате » («необсуждаемых» agile-тем/проблем), включая такие аспекты, как союзы, неудачи и ограничения практик и контекста гибкой разработки программного обеспечения (возможные причины: коммерческие интересы, деконтекстуализация, отсутствие очевидного способа добиваться прогресса на основе неудач, ограниченных объективных данных, когнитивных предубеждений и ошибочных рассуждений), политики и культуры. [136] Как писал Филипп Крухтен :
Agile-движение в некотором смысле похоже на подростка: очень застенчивый, постоянно проверяет свой внешний вид в зеркале, мало принимает критику, заинтересован только в общении со сверстниками, полностью отвергает всю мудрость прошлого только потому, что она он из прошлого, перенимает причуды и новый жаргон, временами дерзкий и высокомерный. Но я не сомневаюсь, что она будет взрослеть и дальше, станет более открытой для внешнего мира, более рефлексивной, а значит, и более эффективной.
- Филипп Крухтен [136]
«Манифест», возможно, оказал негативное влияние на управление и руководство высшим образованием, поскольку он предлагал администраторам заменить более медленные традиционные и совещательные процессы более «гибкими». Эта концепция редко находила признание среди преподавателей университетов. [137]
Другая критика заключается в том, что во многих отношениях гибкое управление и традиционные методы управления в конечном итоге противостоят друг другу. Распространенной критикой этой практики является то, что время, потраченное на ее изучение и внедрение, обходится слишком дорого, несмотря на потенциальные преимущества. Переход от традиционного управления к гибкому управлению требует полного подчинения гибкому подходу и твердой приверженности всех членов организации доведению этого процесса до конца. Такие проблемы, как неравные результаты во всей организации, слишком большие изменения, с которыми сотрудники не могут справиться, или отсутствие гарантий в конце трансформации — это лишь несколько примеров. [138]
{{cite web}}: CS1 maint: неподходящий URL ( ссылка )Статья под названием «Гибкая разработка программного обеспечения: инновационный бизнес»… является еще одной попыткой подорвать дисциплину разработки программного обеспечения… Мы хотим тратить все свое время на программирование. Помните, настоящие программисты не пишут документацию.
95% заявили, что эффекта либо не было, либо произошло снижение затрат... 93% заявили, что производительность стала лучше или значительно лучше... 88% заявили, что качество стало лучше или значительно лучше... 83% заявили, что удовлетворенность бизнесом стала выше или значительно лучше
Только 6% указали, что их производительность снизилась... Об изменении производительности сообщили 34% респондентов, а 60% сообщили о повышении производительности... 66% [ответили], что качество выше... 58% организаций сообщают повышение удовлетворенности, тогда как только 3% сообщают о снижении удовлетворенности.
Что такое самоорганизующаяся команда?
{{cite book}}: CS1 maint: отсутствует местоположение издателя ( ссылка )