Поделиться через

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первая команда 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

команда

команда

спринт

итерация

планировочное спринт-собрание

планировочная игра

См. также

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

Планирование и отслеживание проектов

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

MSF для гибкой разработки программного обеспечения версии 5.0