Принципы и значение гибкой разработки, Джеф Сазерленд (Jeff Sutherland)

Джеф Сазерленд (Jeff Sutherland) создал Scrum в 1993 году, и формализовал его совместно с Кеном Швабером (Ken Schwaber) на конференции OOPSLA в 1995 году. Работая во множестве компаний-разработчиков программного обеспечения, они расширяли и улучшали Scrum, а также участвовали в составлении Agile-манифеста. В блоге Джефа на странице http://scrum.jeffsutherland.com можно ознакомиться с историей создания Scrum и рекомендациями по его применению.

Гибкая разработка — это термин, произошедший от так называемого "Гибкого манифеста" (Agile Manifesto), который был написан в 2001 г. группой, включавшей в себя создателей Scrum, экстремального программирования (XP), метода разработки динамических систем (DSDM) и Crystal; представителя разработки, управляемой функциями; а также некоторых других лидеров мысли из отрасли программного обеспечения. "Гибкий манифест" установил общий набор всеохватывающих ценностей и принципов для всех отдельных гибких методологий, существовавших на то время. Сведения манифеста 4 основных, позволяющих командам при выполнении команды.

• Индивиды и их взаимодействие

• Доставка работающего программного обеспечения

• Сотрудничество с клиентом

• Реакция на изменение

Эти основные ценности поддерживаются 12 принципами, которые можно найти на следующем веб-сайте: Манифест гибкой разработки программного обеспечения.

Эти ценности — не просто пустые и забытые слова создателей "Гибкого манифеста". Они работают. Каждая отдельная гибкая методология подходит к этим ценностям несколько по-разному, но во всех этих методологиях есть конкретные процессы и приемы, благоприятствующие одной или нескольким из этих ценностей.

Индивиды и взаимодействие

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

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

• уважение ценности каждого человека;

• правда при любом общении;

• прозрачность всех данных, действий и решений;

• уверенность, что каждый человек поддержит команду;

• приверженность команде и ее целям.

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

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

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

• Инновации происходят только при свободном обмене конфликтующими идеями; этот феномен был изучен и задокументирован Hirotaka " крещеными и Ikujiro нонака родителями " Scrum.

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

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

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

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

Работающее программное обеспечение вместо всеобъемлющей документации

Работающее программное обеспечение — одно из главных различий, которое приносит гибкая разработка. Все гибкие методологии, представленные в "Гибком манифесте", выделяют необходимость доставки заказчику небольших фрагментов работающего программного обеспечения через заданные интервалы.

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

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

• Определение приемочных тестов при определении функции.

• Реализация функций в порядке приоритета.

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

• Исправьте ошибки, определенных как наивысший приоритет как можно скорее.

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

Сотрудничество с клиентом вместо переговоров по контракту

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

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

Первая команда XP началась с внутреннего ИТ-проекта. Команда XP может иметь пользователя компании на их им удалось привлечь конечного. Примерно 10 процентов времени, и консультантов внутренние команды смогут найти пользователь, который может работать с командой на ежедневной основе. На остальные 90 процентов времени они должны назначить посредника. Такой клиентский посредник, которым команды XP называют заказчика, работает с конечными пользователями, предоставляя четкий упорядоченный по приоритетам список функций, которые должны реализовать разработчики.

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

Реакция на изменение вместо следования плану

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

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

Гибкость это зонтик — методологии это реализации

Гибкая разработка сама по себе не является методологией. Это зонтичный термин, описывающий несколько гибких методологий. При подписании "Гибкого манифеста" в 2001 г. к этим методологиям относились Scrum, XP, Crystal, FDD и DSDM. С тех пор в качестве ценной гибкой методологии также сформировались "рачительные" (Lean) приемы, и поэтому они также внесены под зонтик гибкой разработки на рисунке далее в этом разделе.

Каждая гибкая методология обладает несколько отличающимся подходом к реализации основных ценностей "Гибкого манифеста", так же как и множество компьютерных языков реализует основные функции объектно-ориентированного программирования несколькими способами. Недавнее исследование показало, что примерно 50 процентов практикующих гибкую разработку заявляют, что их команда реализует Scrum. Другие 20 объявили, что они реализуют Scrum с компонентами XP. Еще 12 процентов заявили о том, что реализуют только XP. Так как более 80 процентов реализаций гибкой разработки по всему миру — это Scrum или XP, MSF for Agile Software Development версии 5.0 фокусируется на основных процессах и практических приемах Scrum и XP.

Scrum — это платформа для процессов гибкой разработки. Она не включает в себя конкретные инженерные приемы. Напротив, XP фокусируется на инженерных приемах, но не включает в себя всеохватывающую платформу процессов разработки. Это не значит, что Scrum не рекомендует определенные инженерные приемы, или что в XP нет процесса. Например, первый Scrum реализовал все инженерные приемы, которые теперь известны как XP. Однако платформа Scrum для разработки программного обеспечения была призвана начать работу команды в течение двух или трех дней, в то время как для реализации инженерных приемов часто требуются многие месяцы. Поэтому вопрос, когда (и стоит ли) внедрять те или иные приемы, остается на рассмотрение каждой команды. Соавторы Scrum Джеф Сазерленд и Кен Швабер рекомендуют командам Scrum немедленно начинать работу и создать список препятствий и план улучшения процесса. Так как инженерные приемы идентифицируются как препятствия, командам следует обращаться к приемам XP как к способу улучшения. Лучшие команды реализуют Scrum, дополненный приемами XP. Scrum помогает XP масштабироваться, а XP способствует надлежащей работе Scrum.

В следующей таблице показано, как взаимозаменяются ключевые термины Scrum и XP.

Scrum	XP
владелец продукта	пользователь
координатор	тренер XP
команда	команда
спринт	итерация
планировочное спринт-собрание	планировочная игра

См. также

Основные понятия

Отслеживание работ с помощью Visual Studio ALM и TFS

Другие ресурсы

MSF for Agile Software Development для Visual Studio ALM