Войти
В разработка программного обеспечения, гибкая (иногда пишется как Agile ), подход к выявлению требований и разработке решений посредством совместных усилий самоорганизующихся и кросс-функциональных команд и их клиентов. (и) / конечный пользователь (и). Он выступает за адаптивное планирование, эволюционную разработку, раннюю поставку и постоянное улучшение и поощряет гибкую реакцию на изменения.
Его популяризировал Манифест гибкой разработки программного обеспечения. Ценности и принципы, провозглашенные в этом манифесте, были основаны на широком диапазоне сред разработки программного обеспечения, включая Scrum и Kanban.
, и лежат в их основе, хотя существует множество анекдотических свидетельств того, что принятие гибких практик и ценностей повышает гибкость специалистов по программному обеспечению, команд и организаций, эмпирические данные неоднозначны, и их трудно найти.
Итерационные и инкрементные методы разработки программного обеспечения можно проследить еще в 1957 году, когда эволюционное управление проектами и адаптивная разработка программного обеспечения появились в начале 1970-х годов.
В 1990-х годах ряд Облегченных методов разработки программного обеспечения развились в ответ на преобладающие тяжелые методы (часто именуемые вместе как водопад ), которые критики описали как чрезмерно регулируемые, запланированные и микроуправляемые. К ним относятся: быстрая разработка приложений (RAD) с 1991 г.; унифицированный процесс (UP) и метод разработки динамических систем (DSDM), оба с 1994 г.; Scrum, с 1995 г.; Crystal Clear и экстремальное программирование (XP), оба с 1996 г.; и разработка, управляемая функциями, с 1997 года. Хотя все они возникли до публикации Agile Manifesto, теперь все вместе они именуются гибкими методами разработки программного обеспечения. В то же время аналогичные изменения происходили в производственном и управленческом мышлении.
В 2001 году эти семнадцать разработчиков программного обеспечения встретились на курорте в Snowbird, Юта, чтобы обсудить эти облегченные методы разработки: Кент Бек, Уорд Каннингем, Дэйв Томас, Джефф Сазерленд, Кен Швабер, Джим Хайсмит, Алистер Кокберн, Роберт К. Мартин, Майк Бидл, Мартин Фаулер, Джеймс Греннинг, Эндрю Хант, Рон Джеффрис, Брайан Марик и Стив Меллор. Вместе они опубликовали Манифест гибкой разработки программного обеспечения.
В 2005 году группа, возглавляемая Кокберном и Хайсмитом, написала приложение принципов управления проектами, Декларацию о взаимозависимости PM, для руководства проектом программного обеспечения. управление в соответствии с методами гибкой разработки программного обеспечения.
В 2009 году группа, работающая с Мартином, написала расширение принципов разработки программного обеспечения, Манифест мастерства программного обеспечения, чтобы направлять гибкую разработку программного обеспечения в соответствии с профессионалом поведение и мастерство.
В 2011 году Agile Alliance создал Руководство по гибким методам разработки (в 2016 году переименовано в Agile Glossary), развивающийся открытый сборник рабочих определений гибких практик, терминов и элементов, а также их интерпретаций и ознакомьтесь с рекомендациями мирового сообщества практиков Agile.
Основываясь на совместном опыте разработки программного обеспечения и помощи другим в этом, семнадцать подписантов манифеста заявили, что для них важнее:
То есть предметы слева ценятся больше, чем предметы справа.
Как пояснил Скотт Амблер :
Некоторые из авторов сформировали Agile Alliance, некоммерческую организацию, которая продвигает разработку программного обеспечения в соответствии с ценностями и принципами манифеста. Представляя манифест от имени Agile Alliance, Джим Хайсмит сказал:
Agile-движение не является анти-методологией, на самом деле многие из нас хотят восстановить доверие к слову «методология». Мы хотим восстановить баланс. Мы принимаем моделирование, но не для того, чтобы поместить какую-нибудь схему в пыльный корпоративный репозиторий. Мы принимаем документацию, но не сотни страниц никогда не обслуживаемых и редко используемых фолиантов. Мы планируем, но осознаем ограниченность планирования в неспокойной среде. Те, кто называет сторонников XP, SCRUM или любой другой гибкой методологии «хакерами», не знают ни методологий, ни оригинального определения термина хакер.
— Джим Хайсмит, History: The Agile ManifestoМанифест гибкой разработки программного обеспечения основан на двенадцати принципах:
Парное программирование, метод гибкой разработки, используемый XP.наиболее гибким Методы разработки разбивают работу по разработке продукта на небольшие этапы, которые сводят к минимуму объем предварительного планирования и проектирования. Итерации, или спринты, представляют собой короткие временные рамки (временные рамки ), которые обычно длятся от одной до четырех недель. Каждая итерация включает кросс-функциональную команду, работающую над всеми функциями: планирование, анализ, дизайн, кодирование, модульное тестирование и приемочное тестирование. В конце итерации заинтересованным сторонам демонстрируется рабочий продукт. Это сводит к минимуму общий риск и позволяет продукту быстро адаптироваться к изменениям. Итерация может не добавить достаточно функциональности, чтобы гарантировать выпуск на рынок, но цель состоит в том, чтобы иметь доступный выпуск (с минимальным количеством ошибок ) в конце каждой итерации. Для выпуска продукта или новых функций может потребоваться несколько итераций. Основным критерием прогресса является рабочее программное обеспечение.
Принцип совместного размещения заключается в том, что сотрудники в одной команде должны располагаться вместе, чтобы лучше идентифицировать себя как команду и улучшить общение. Это позволяет взаимодействовать лицом к лицу, в идеале перед интерактивной доской, что сокращает время цикла, которое обычно занимает, когда вопросы и ответы передаются через телефон, постоянный чат, вики или электронную почту.
Независимо от того, какой метод разработки используется, в каждую команду следует включать представителя заказчика («Владелец продукта» в Scrum ). Этот человек согласован заинтересованными сторонами действовать от их имени и берет на себя личное обязательство быть доступным разработчикам для ответов на вопросы на протяжении всей итерации. В конце каждой итерации заинтересованные стороны и представитель клиента проверяют прогресс и повторно оценивают приоритеты с целью оптимизации возврата инвестиций (ROI) и обеспечения соответствия потребностям клиентов и целям компании.
При быстрой разработке программного обеспечения информационный излучатель представляет собой (обычно большой) физический дисплей, расположенный на видном месте рядом с командой разработчиков, где его могут видеть прохожие. Он представляет собой актуальную сводку о состоянии разработки продукта. Световой индикатор сборки также может использоваться для информирования команды о текущем статусе разработки продукта.
Общей характеристикой гибкой разработки программного обеспечения является ежедневный стендап (ежедневная схватка в среде Scrum). Во время короткого сеанса члены команды сообщают друг другу, что они сделали накануне для достижения цели итерации своей команды, что они собираются сделать сегодня для достижения цели, а также обо всех препятствиях или препятствиях, которые они могут увидеть на пути к цели.
Специальные инструменты и методы, такие как непрерывная интеграция, автоматическое модульное тестирование, парное программирование, управляемое тестированием разработка, шаблоны проектирования, разработка на основе поведения, дизайн на основе предметной области, рефакторинг кода и другие методы. для повышения качества и повышения гибкости разработки продукта. Это зависит от качества проектирования и создания с самого начала и возможности продемонстрировать программное обеспечение для клиентов в любой момент или, по крайней мере, в конце каждой итерации.
По сравнению с традиционными программная инженерия, гибкая разработка программного обеспечения в основном нацелены на сложные системы и разработку продуктов с динамическими, недетерминированными и нелинейными характеристиками. Точные оценки, стабильные планы и прогнозы часто трудно получить на ранних этапах, и доверие к ним, вероятно, будет низким. Практикующие Agile будут стремиться уменьшить «прыжок веры», который необходим, прежде чем можно будет получить какое-либо доказательство ценности. Требования и дизайн считаются возникающими. В таких случаях большие предварительные спецификации, вероятно, привели бы к большим потерям, т. Е. Экономически невыгодны. Эти основные аргументы и предыдущий отраслевой опыт, извлеченный из многолетних успехов и неудач, помогли сформировать предпочтение гибкой разработки в отношении адаптивной, итеративной и эволюционной разработки.
Методы разработки существуют на континуум от адаптивного к прогнозирующему. Методы гибкой разработки программного обеспечения находятся на адаптивной стороне этого континуума. Одним из ключевых элементов адаптивных методов разработки является подход скользящей волны к планированию расписания, который определяет вехи, но оставляет гибкость на пути их достижения, а также позволяет изменять сами вехи.
Адаптивные методы ориентированы на быструю адаптацию к меняющимся реалиям. Когда меняются потребности проекта, меняется и адаптивная команда. Адаптивной команде сложно точно описать, что произойдет в будущем. Чем дальше дата, тем более неопределенным является адаптивный метод относительно того, что произойдет в эту дату. Адаптивная команда не может точно сообщить, какие задачи они будут выполнять на следующей неделе, а только то, какие функции они планируют на следующий месяц. Отвечая на вопрос о выпуске через шесть месяцев, адаптивная команда могла бы сообщить только формулировку миссии для выпуска или формулировку ожидаемой ценности по сравнению с затратами.
Методы прогнозирования, напротив, сосредоточены на детальном анализе и планировании будущего и учитывают известные риски. В крайнем случае, группа прогнозирования может точно сообщить, какие функции и задачи запланированы на протяжении всего процесса разработки. Прогностические методы основаны на эффективном анализе на ранней стадии, и если это пойдет не так, проекту может быть сложно изменить направление. Группы прогнозирования часто создают панель управления изменениями, чтобы гарантировать, что они учитывают только самые ценные изменения.
Анализ рисков может использоваться для выбора между адаптивными (гибкими или ориентированными на ценность) и прогнозирующими (плановыми) методами. Барри Бём и Ричард Тернер предполагают, что каждая сторона континуума имеет свою собственную основу, а именно:
| Методы, ориентированные на ценность | Методы, основанные на планах | Формальные методы |
|---|---|---|
| Низкая критичность | Высокая критичность | Высокая критичность |
| Старшие разработчики | Младшие разработчики (?) | Старшие разработчики |
| Требования часто меняются | Требования не меняются часто | Ограниченные требования, ограниченные возможности см. закон Вирта |
| Небольшое количество разработчиков | Большое количество разработчиков | Требования, которые можно смоделировать |
| Культура, которая реагирует на изменения | Культура, требующая порядка | Высочайшее качество |
Одно из различий между Agile методы разработки программного обеспечения и водопад - это Подход к качеству и тестированию. В каскадной модели работа проходит через этапы жизненного цикла разработки программного обеспечения (SDLC), при этом одна фаза завершается до начала другой, поэтому фаза тестирования является отдельной и следует за этапом сборки . Однако при гибкой разработке программного обеспечения тестирование выполняется в той же итерации, что и программирование.
Поскольку тестирование проводится на каждой итерации, при которой разрабатывается небольшая часть программного обеспечения, пользователи могут часто использовать эти новые части программного обеспечения и проверять ценность. После того, как пользователи узнают реальную ценность обновленного программного обеспечения, они могут принимать более обоснованные решения о будущем программного обеспечения. Наличие ретроспективы ценности и сеанса перепланирования программного обеспечения на каждой итерации - Scrum обычно состоит из двух недель - помогает команде постоянно адаптировать свои планы, чтобы максимизировать ценность, которую они приносят. Это следует шаблону, аналогичному циклу Планирование-Выполнение-Проверка-Действие (PDCA), поскольку работа планируется, выполняется, проверяется (в обзоре и ретроспективе), а любые согласованные изменения учитываются.
Этот итеративный подход поддерживает мышление продукта, а не проекта. Это обеспечивает большую гибкость в процессе разработки; тогда как в проектах требования определены и заблокированы с самого начала, что затрудняет их изменение позже. Итеративная разработка продукта позволяет программному обеспечению развиваться в ответ на изменения бизнес-среды или требований рынка.
Благодаря короткому итерационному стилю гибкой разработки программного обеспечения, оно также имеет прочные связи с бережливым стартапом концепция.
В письме в IEEE Computer Стивен Ракитин выразил цинизм по поводу гибкой разработки программного обеспечения, назвав это «еще одной попыткой подорвать дисциплину программного обеспечения. разработка "и перевод" работающее программное обеспечение вместо исчерпывающей документации "на" мы хотим тратить все свое время на программирование. Помните, настоящие программисты не пишут документацию ".
Это оспаривается сторонниками гибкой разработки программного обеспечения, которые заявляют, что разработчики должны писать документацию, если это лучший способ достижения соответствующих целей, но что часто есть более эффективные способы достижения этих целей, чем написание статической документации. Скотт Эмблер утверждает, что документация должна быть «едва ли достаточно хорошо »(JBGE), слишком большая или полная документация обычно приводит к расточительству, а разработчики редко доверяют подробной документации, потому что она обычно не синхронизируется с кодом, а слишком мало документации также может вызвать проблемы для обслуживания, c общение, обучение и обмен знаниями. Алистер Кокберн писал о методе Crystal Clear:
Crystal рассматривает разработку как серию совместных игр и намеревается, что документации будет достаточно, чтобы помочь следующей победе в следующей игре. Рабочие продукты для Crystal включают варианты использования, список рисков, план итераций, модели основной предметной области и заметки по дизайну для информирования о вариантах выбора... однако для этих документов нет шаблонов, и описания обязательно расплывчаты, но цель ясна, документации хватит для следующей игры. Я всегда склонен характеризовать это для своей команды так: что бы вы хотели знать, если бы присоединились к команде завтра.
— Алистер Кокберн.
Поддержка жизненного цикла разработки программного обеспечения Agile Методы разработки программного обеспечения поддерживают широкий диапазон жизненного цикла разработки программного обеспечения. Некоторые методы ориентированы на практики (например, XP, прагматическое программирование, гибкое моделирование), а некоторые - на управление потоком работы (например, Scrum, Kanban). Некоторые виды деятельности поддерживают спецификацию требований и разработку (например, FDD), в то время как другие стремятся охватить полный жизненный цикл разработки (например, DSDM, RUP ).
Среди известных фреймворков гибкой разработки программного обеспечения:
| Framework | Основной участник (и) |
|---|---|
| Адаптивная разработка программного обеспечения (ASD) | Джим Хайсмит, Сэм Bayer |
| Гибкое моделирование | Скотт Амблер, Роберт Сесил Мартин |
| Гибкий унифицированный процесс (AUP) | Скотт Эмблер |
| Дисциплинированная гибкая доставка | Скотт Амблер |
| Метод разработки динамических систем (DSDM) | |
| Экстремальное программирование (XP) | Кент Бек, Роберт Сесил Мартин |
| Разработка, управляемая функциями (FDD) | Джефф Де Лука |
| Бережливая разработка программного обеспечения | Мэри Поппендик, Том Поппендик |
| Бережливый стартап | Эрик Рис |
| Канбан | Тайити Оно |
| Быстрая разработка приложений ( RAD) | Джеймс Мартин |
| Scrum | Кен Швабер, Джефф Сазерленд |
| Scrumban | |
| Scaled Agile Framework - SAFe | Scaled Agile, Inc. |
Гибкая разработка программного обеспечения поддерживается рядом конкретных практик, охватывающих такие области, как требования, дизайн, моделирование, кодирование, тестирование, планирование, управление рисками, процесс, качество и т. д. Некоторые известные практики гибкой разработки программного обеспечения включают:
| Практика | Основной участник (и) |
|---|---|
| Разработка через приемочное тестирование (ATDD) | |
| Гибкое моделирование | |
| Гибкое тестирование | |
| Бэклог (продукт и спринт) | Кен Швабер |
| Поведенческая разработка (BDD) | Дэн Норт, Лиз Кио |
| Непрерывная интеграция (CI) | Грэди Буч |
| Межфункциональная команда | |
| Daily Stand-up / Daily Scrum | Джеймс О Коплиен |
| Домен- управляемый дизайн (DDD) | Эрик Эванс |
| Итеративная и инкрементная разработка (IID) | |
| Платформы разработки с низким уровнем кода | |
| Парное программирование | Кент Бек |
| Планирование покера | Джеймс Греннинг, Майк Кон |
| Рефакторинг | Мартин Фаулер |
| Ретроспектива | |
| События Scrum (планирование спринта, обзор спринта и ретроспектива) | |
| Уточнение на примере | |
| Моделирование на основе сюжета | Альберт Цюндорф |
| Разработка через тестирование (TDD) | Кент Бек |
| Время бокс | |
| История пользователя | Алистер Кокберн |
| Отслеживание скорости |
В литературе разные термины относятся к понятию адаптации метода, включая «адаптацию метода», «фрагмент метода» адаптация »и« инженерия ситуационных методов ». Адаптация метода определяется как:
процесс или возможность, в которых агенты-люди определяют подход к разработке системы для конкретной ситуации проекта посредством реагирующих изменений и динамического взаимодействия между контекстами, намерениями и фрагментами методов.
— Мехмет Нафиз Айдын и др., Метод разработки гибких информационных систем в использованииСоответствие ситуации следует рассматривать как отличительную характеристику между гибкими методами и методами разработки программного обеспечения, в большей степени основанными на планах, с гибкими методами, позволяющими группам разработки продуктов адаптировать рабочие практики в соответствии с потребности отдельных продуктов. Потенциально наиболее гибкие методы могут быть подходящими для адаптации методов, например, DSDM, адаптированный в контексте CMM. и XP, адаптированный к технике описания правил (RDP). Однако не все сторонники Agile согласны с тем, что Швабер отмечает, что «именно поэтому мы в первую очередь попали в беду, думая, что проблема заключалась в отсутствии совершенной методологии. Усилия [должны] сосредоточиваться на изменениях [необходимых] на предприятии».. Бас Водде усилил эту точку зрения, предположив, что в отличие от традиционных крупных методологий, требующих от вас выбора элементов, Scrum предоставляет основы, поверх которых вы добавляете дополнительные элементы для локализации и контекстуализации его использования. Практики редко используют методы разработки систем, или, в частности, гибкие методы, по инструкции, часто предпочитая опустить или адаптировать некоторые практики метода, чтобы создать собственный метод.
На практике методы могут быть адаптированным с использованием различных инструментов. Общие языки моделирования процессов, такие как Unified Modeling Language, могут использоваться для адаптации методов разработки программного обеспечения. Тем не менее, также существуют специальные инструменты для разработки методов, такие как Essence Theory of Software Engineering of SEMAT.
Гибкая разработка программного обеспечения была широко считается подходящим для определенных типов сред, включая небольшие группы экспертов, работающих над проектами с нуля, а также с проблемами и ограничениями, возникающими при внедрении гибких методов разработки программного обеспечения в крупной организации с наследием инфраструктура хорошо документированы и понятны.
В ответ на это был разработан ряд стратегий и шаблонов для преодоления проблем, связанных с крупномасштабной разработкой (>20 разработчиков) или распределенной (не-колокационной) разработкой команды, среди прочего; и в настоящее время существует несколько признанных структур, которые стремятся смягчить или избежать этих проблем.
Существует множество противоречивых точек зрения на то, все ли они эффективны или действительно соответствуют определению гибкой разработки, и это остается активной и постоянной областью исследований.
Когда гибкая разработка программного обеспечения применяется в распределенной среде (с командами, разбросанными по нескольким офисам), его обычно называют Распределенная гибкая разработка программного обеспечения. Цель состоит в том, чтобы максимально использовать уникальные преимущества каждого подхода. Распределенная разработка позволяет организациям создавать программное обеспечение, стратегически создавая команды в разных частях земного шара, виртуально создавая программное обеспечение круглосуточно (что чаще называют моделью «следования за солнцем»). С другой стороны, гибкая разработка обеспечивает повышенную прозрачность, постоянную обратную связь и большую гибкость при реагировании на изменения.
Методы гибкой разработки программного обеспечения изначально рассматривались как наиболее подходящие для некритических разработок продуктов, поэтому были исключены из использования в регулируемых областях, таких как медицинские устройства, фармацевтика, финансовый сектор, ядерные системы, автомобилестроение, авионика и т. д. Однако за последние несколько лет было выдвинуто несколько инициатив по адаптации гибких методов для этих областей.
Существует множество стандартов, которые могут применяться в регулируемых областях, включая ISO 26262, ISO 9000, ISO 9001 и ISO / IEC 15504. Ряд ключевых проблем имеет особое значение в регулируемых областях:
Хотя гибкие методы разработки программного обеспечения могут использоваться на практике с любой парадигмой программирования или языком, они изначально были тесно связаны с objec t-ориентированные среды, такие как Smalltalk и Lisp, а затем Java. Первоначальными приверженцами гибких методов обычно были небольшие и средние команды, работавшие над беспрецедентными системами с требованиями, которые было трудно завершить и которые, вероятно, изменились по мере разработки системы. В этом разделе описаны общие проблемы, с которыми сталкиваются организации, когда они пытаются внедрить методы гибкой разработки программного обеспечения, а также различные методы для измерения качества и производительности гибких команд.
Лучшие специалисты в области гибкости всегда подчеркивали основательные инженерные принципы. В результате существует ряд передовых методов и инструментов для измерения производительности гибкой разработки программного обеспечения и групп.
Индекс измерения гибкости, среди прочего, оценивает разработки по пяти параметрам разработки продукта (продолжительность, риск, новизна, усилия и взаимодействие). Другие методы основаны на измеримых целях, и одно исследование показывает, что скорость может использоваться как показатель гибкости. Также существует гибкая самооценка, позволяющая определить, использует ли команда методы гибкой разработки программного обеспечения (тест Nokia, тест Карлскрона, тест 42 балла).
Одно из первых исследований, в которых сообщается Повышение качества, производительности и удовлетворенности бизнеса за счет использования методов гибкой разработки программного обеспечения - это исследование, проведенное Shine Technologies с ноября 2002 г. по январь 2003 г.
Аналогичное исследование State of Agile проводится ежегодно, начиная с 2006 год с тысячами участников из всего сообщества разработчиков программного обеспечения. Это отслеживает тенденции в отношении преимуществ гибкости, извлеченных уроков и передовых методов. В каждом опросе сообщалось о росте числа заявлений о том, что гибкая разработка программного обеспечения помогает им быстрее выпускать программное обеспечение; улучшает их способность управлять изменяющимися приоритетами клиентов; и увеличивает их производительность. Опросы также неизменно показывают лучшие результаты при использовании гибких методов разработки продуктов по сравнению с классическим управлением проектами. В целом, есть сообщения о том, что некоторые считают, что методы гибкой разработки еще слишком молоды, чтобы проводить обширные академические исследования их успеха.
Организации и группы, внедряющие гибкую разработку программного обеспечения часто сталкиваются с трудностями при переходе от более традиционных методов, таких как каскадная разработка, например, когда командам навязывают гибкий процесс. Их часто называют проворными антипаттернами или более часто проворными запахами. Ниже приведены некоторые распространенные примеры:
Цель гибкой разработки программного обеспечения - сосредоточиться на создании рабочего программного обеспечения и меньше на документации. Это контрастирует с каскадными моделями, где процесс часто строго контролируется, а незначительные изменения в системе требуют значительного пересмотра сопроводительной документации. Однако это не оправдывает полного отказа от анализа или проектирования. Отсутствие внимания к дизайну может привести к тому, что команда поначалу будет действовать быстро, но затем потребуется существенная переделка, когда они попытаются масштабировать систему. Одна из ключевых особенностей гибкой разработки программного обеспечения - это итеративность. Когда все сделано правильно, дизайн проявляется по мере разработки системы и выявления общих черт и возможностей для повторного использования.
При гибкой разработке программного обеспечения истории (аналогичные варианты использования описания) обычно используются для определения требований, а итерация - это короткий промежуток времени, в течение которого команда выполняет определенные задачи. Добавление историй в текущую итерацию пагубно сказывается на рабочем процессе. Они должны быть добавлены в список невыполненных работ по продукту и иметь приоритет для следующей итерации, или в редких случаях итерация может быть отменена.
Это не означает, что история не может расширяться. Команды должны иметь дело с новой информацией, которая может создать дополнительные задачи для рассказа. Если новая информация не позволяет завершить историю во время итерации, то ее следует перенести на следующую итерацию. Тем не менее, он должен иметь приоритет по сравнению со всеми оставшимися историями, поскольку новая информация могла изменить первоначальный приоритет истории.
Гибкая разработка программного обеспечения часто осуществляется на низовом уровне в организациях группами разработчиков программного обеспечения, которые пытаются оптимизировать свои процессы разработки и обеспечить согласованность в жизненном цикле разработки программного обеспечения. Не имея спонсорской поддержки, команды могут столкнуться с трудностями и сопротивлением со стороны деловых партнеров, других команд разработчиков и руководства. Кроме того, они могут пострадать без соответствующего финансирования и ресурсов. Это увеличивает вероятность отказа.
Опрос, проведенный VersionOne, показал, что респонденты назвали недостаточное обучение как наиболее значительную причину неудачных внедрений Agile. Команды попали в ловушку, предполагая сокращение Процессы гибкой разработки программного обеспечения по сравнению с другими методологиями, такими как водопад, означает отсутствие реальных правил для гибкой разработки программного обеспечения.
владелец продукта отвечает за представление бизнеса в процессе разработки и часто является самой сложной ролью.
Распространенной ошибкой является то, что роль владельца продукта исполняет кто-то из команды разработчиков. Это требует от команды принятия собственных решений по расстановке приоритетов без реальной обратной связи со стороны бизнеса. Они пытаются решать бизнес-задачи внутри компании или откладывают работу, обращаясь за указаниями за пределы команды. Это часто приводит к отвлечению внимания и нарушению совместной работы.
Гибкая разработка программного обеспечения требует от команд выполнения обязательств по продукту, а это означает, что они должны сосредоточиться только на работе над этим продуктом. Тем не менее, от членов команды, которые кажутся свободными, часто ожидается, что они возьмут на себя другую работу, что затрудняет их выполнение работы, которой они занимались.
Команды могут попасть в ловушку, тратя слишком много времени на подготовку или планирование. Это обычная ловушка для команд, менее знакомых с гибкой разработкой программного обеспечения, когда команды чувствуют себя обязанными иметь полное понимание и спецификацию всех историй. Команды должны быть готовы продвигаться вперед только с теми историями, в которых они уверены, а затем во время итерации продолжать обнаруживать и готовить работу для последующих итераций (часто это называется уточнение невыполненных работ или обработка).
Ежедневный стендап должен быть целенаправленным и своевременным собранием, на котором все члены команды распространяют информацию. Если происходит решение проблемы, часто в нем могут участвовать только определенные члены команды, и потенциально это не лучшее использование времени всей команды. Если во время ежедневного стендапа команда начинает погружаться в решение проблем, его следует отложить до тех пор, пока подгруппа не сможет обсудить, обычно сразу после завершения стендапа.
Одно из предполагаемые преимущества гибкой разработки программного обеспечения заключаются в том, чтобы дать команде возможность делать выбор, поскольку он ближе всего к проблеме. Кроме того, они должны делать выбор как можно ближе к реализации, чтобы использовать более своевременную информацию при принятии решения. Если члены команды поручают задачи другим или слишком рано в процессе, преимущества локализованного и своевременного принятия решений могут быть потеряны.
Назначение работы также ограничивает членов команды определенными ролями (например, член команды A должен всегда выполнять работу с базой данных), что ограничивает возможности для перекрестного обучения. Члены команды сами могут решать задачи, расширяющие их возможности и предоставляющие возможности для перекрестного обучения.
Скрам-мастер - это человек, ответственный за обеспечение того, чтобы процесс схватки происходил, и инструктаж команды схватки через этот процесс. Распространенная ошибка состоит в том, что мастер схватки выступает в роли контрагента. дистрибьютор. Хотя это и не запрещено методологией Scrum, мастер схватки должен убедиться, что у него есть способность сначала действовать в роли мастера схватки, а не работать над задачами разработки. Роль мастера схватки состоит в том, чтобы облегчить процесс, а не создавать продукт.
Если мастер схватки также выполняет многозадачность, это может привести к слишком большому количеству переключений контекста, чтобы быть продуктивным. Кроме того, поскольку мастер схватки отвечает за устранение препятствий, чтобы команда могла двигаться вперед, выгода, получаемая от продвижения отдельных задач, может не перевешивать препятствия, которые откладываются из-за нехватки возможностей.
Из-за итеративного характера гибкой разработки часто требуется несколько раундов тестирования. Автоматическое тестирование помогает снизить влияние повторяющихся модульных, интеграционных и регрессионных тестов и позволяет разработчикам и тестировщикам сосредоточиться на более ценной работе.
Автоматизация тестирования также поддерживает непрерывный рефакторинг, необходимый для итеративной разработки программного обеспечения. Разрешение разработчику быстро запускать тесты для подтверждения того, что рефакторинг не изменил функциональность приложения, может снизить рабочую нагрузку и повысить уверенность в том, что усилия по очистке не привели к появлению новых дефектов.
Сосредоточение внимания на предоставлении новых функций может привести к увеличению технического долга. Команда должна дать себе время для исправления дефектов и рефакторинга. Технический долг мешает планированию из-за увеличения объема внеплановой работы, поскольку производственные дефекты отвлекают команду от дальнейшего прогресса.
По мере развития системы важно провести рефакторинг, поскольку энтропия системы естественным образом увеличивается. Со временем отсутствие постоянного обслуживания приводит к увеличению дефектов и затрат на разработку.
Распространенное заблуждение состоит в том, что гибкая разработка программного обеспечения допускает непрерывные изменения, но итерацию backlog - это соглашение о том, какую работу можно выполнить во время итерации. Слишком много незавершенной работы (WIP) приводит к неэффективности, такой как переключение контекста и организация очередей. Команда не должна чувствовать давления, заставляющего выполнять дополнительную работу.
Гибкая разработка программного обеспечения заранее определяет время (продолжительность итерации), качество и, в идеале, ресурсы (хотя поддержание фиксированных ресурсов может быть затруднено, если разработчиков часто отвлекают от задач для обработки производственных инцидентов), при этом объем остается переменным. Заказчик или владелец продукта часто настаивают на фиксированном объеме итерации. Тем не менее, команды не должны стремиться к ограниченному времени, ресурсам и объему (обычно известному как треугольник управления проектом ). Попытки увеличить объем к фиксированному времени и ресурсам гибкой разработки программного обеспечения могут привести к снижению качества.
Из-за целенаправленного темпа и непрерывного характера гибких практик наблюдается повышенный риск выгорания среди членов команды доставки.
Термин гибкое управление применяется к итеративному, инкрементному методу управления проектированием и сборкой инженерных, информационных технологий и других области бизнеса, которые стремятся обеспечить разработку новых продуктов или услуг в очень гибкой и интерактивной манере на основе принципов, изложенных в Манифесте для гибкой разработки программного обеспечения.
Методы Agile X также можно назвать экстремальным проектом управление. Это вариант итеративного жизненного цикла, где результаты предоставляются поэтапно. Основное различие между гибкой и итеративной разработкой заключается в том, что гибкие методы завершают небольшие части результатов в каждом цикле доставки (итерации), в то время как итерационные методы развивают весь набор результатов с течением времени, завершая их ближе к концу проекта. Итеративные и гибкие методы были разработаны как реакция на различные препятствия, возникшие в более последовательных формах организации проекта. Например, по мере того, как технологические проекты становятся все сложнее, конечные пользователи, как правило, испытывают трудности с определением долгосрочных требований, не имея возможности просматривать прогрессивные прототипы. Проекты, которые развиваются в итерациях, могут постоянно собирать отзывы, чтобы помочь уточнить эти требования.
Гибкое управление также предлагает простую структуру, способствующую общению и размышлению о прошлой работе среди членов команды. Команды, которые использовали традиционное водопадное планирование и выбрали гибкий путь разработки, обычно проходят фазу трансформации и часто получают помощь от гибких тренеров, которые помогают командам пройти плавную трансформацию. Обычно существует два стиля agile-коучинга: на основе push и. Подходы к гибкому управлению также были применены и адаптированы к бизнесу и правительству. Например, в рамках федерального правительства США, Агентство США по международному развитию (USAID) использует подход совместного управления проектами, который фокусируется на включение стратегий сотрудничества, обучения и адаптации (CLA) для итерации и адаптации программирования.
Гибкие методы упоминаются в Руководстве по своду знаний по управлению проектами (PMBOK Guide) в рамках жизненного цикла проекта определение:
Адаптивный жизненный цикл проекта , жизненный цикл проекта, также известный как управляемые изменениями или гибкие методы, который предназначен для облегчения изменений и требует высокой степени постоянного участия заинтересованных сторон. Адаптивные жизненные циклы также являются итеративными и инкрементными, но отличаются тем, что итерации очень быстрые (обычно длятся 2-4 недели) и фиксированы по времени и ресурсам.
Конференция по Agile Brazil 2014 По словам Жан-Лу Рише (научный сотрудник ESSEC Институт стратегических инноваций и услуг), «этот подход может быть эффективно использован для непрограммных продуктов и для управления проектами в целом, особенно в областях инновации и неопределенность ». Конечным результатом является продукт или проект, который наилучшим образом удовлетворяет текущие потребности клиентов и доставляется с минимальными затратами, отходами и временем, что позволяет компаниям достичь чистой прибыли раньше, чем с помощью традиционных подходов. широко использовались для разработки программных продуктов, а некоторые из них используют определенные характеристики программного обеспечения, такие как объектные технологии. Однако эти методы можно применять для разработки непрограммных продуктов, таких как компьютеры, медицинские устройства, продукты питания, одежда и музыка. Методы гибкой разработки программного обеспечения использовались в ИТ-инфраструктуре , не связанных с разработкой, при развертывании и миграции. Некоторые из более широких принципов гибкой разработки программного обеспечения также нашли применение в общем управлении (например, стратегия, управление, риски, финансы) в рамках терминов гибкость бизнеса или гибкое управление бизнесом.
Парадигмы гибкой разработки программного обеспечения можно использовать в других сферах жизни, например, в воспитании детей. Его успех в развитии ребенка может быть основан на некоторых основных принципах управления; общение, адаптация и осведомленность. В TED Talk Брюс Фейлер поделился тем, как он применил базовые парадигмы гибкой разработки к ведению домашнего хозяйства и воспитанию детей.
Практики гибкой разработки могут быть неэффективными в крупных организациях и некоторых виды разработок. Многие организации считают, что методологии гибкой разработки программного обеспечения слишком экстремальны, и применяют гибридный подход, сочетающий элементы гибкой разработки программного обеспечения и подходов, основанных на планах. Некоторые методы, такие как метод разработки динамических систем (DSDM), делают попытку этого дисциплинированно, без ущерба для фундаментальных принципов.
Растущее внедрение гибких практик также подвергалось критике как управленческая причуда, которая просто описывает существующие передовые практики на новом жаргоне, продвигает единый подход к стратегиям развития и ошибочно делает упор на метод, а не на результат.
Алистер Кокберн организовал празднование 10-й годовщины Манифеста по гибкой разработке программного обеспечения в Сноуберд, штат Юта, 12 февраля 2011 года, собрав около 30+ человек, участвовавших в первоначальной встрече, и поскольку. Был собран список примерно из 20 слонов в комнате («не подлежащие обсуждению» темы / вопросы Agile), включая аспекты: альянсы, неудачи и ограничения методов и контекста гибкой разработки программного обеспечения (возможные причины: коммерческие интересы, деконтекстуализация, отсутствие очевидного способа добиться прогресса на основе неудач, ограниченных объективных свидетельств, когнитивных предубеждений и логических ошибок), политики и культуры. Как Филипп Крюхтен писал:
Agile-движение в некотором роде немного похоже на подростка: очень застенчиво, постоянно проверяет свое появление в зеркале, принимает немного критики, заинтересовано только в том, чтобы быть со своим сверстники, целиком отвергая всю мудрость прошлого только потому, что она пришла из прошлого, перенимают причуды и новый жаргон, временами дерзко и высокомерно. Но я не сомневаюсь, что он будет развиваться дальше, станет более открытым для внешнего мира, более рефлексивным и, следовательно, более эффективным.
— Philippe Kruchten«Манифест», возможно, оказал негативное влияние на менеджмент высшего образования и лидерство, где администраторам предлагалось заменить более медленные традиционные и совещательные процессы более «проворными». Эта концепция никогда не находила признания среди преподавателей университетов.
Еще одна критика заключается в том, что во многих отношениях гибкое управление и традиционные методы управления в конечном итоге противоречат друг другу. Распространенная критика этой практики заключается в том, что время, потраченное на попытки изучить и внедрить эту практику, обходится слишком дорого, несмотря на потенциальные выгоды. Переход от традиционного управления к гибкому управлению требует полного подчинения Agile и твердой приверженности всех членов организации довести процесс до конца. Такие проблемы, как неравные результаты во всей организации, слишком большие изменения, с которыми сотрудники не могут справиться, или отсутствие гарантий в конце трансформации - лишь несколько примеров.
