Полная версия

Главная arrow Информатика arrow Архитектура и проектирование программных систем

  • Увеличить шрифт
  • Уменьшить шрифт


<<   СОДЕРЖАНИЕ   >>

Agile-мemoдoлoгuu

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

  • 1. Разработка ведется короткими итерациями. Чем короче итерация, тем чаще можно демонстрировать продукт заказчику и изменять направление развития продукта. Заказчик сможет руководить разработкой продукта, вместо того чтобы, дождавшись окончания разработки, понять, что получилось совсем не то, что он хотел.
  • 2. Инкрементальная разработка. За каждую итерацию продукт дополняется новыми функциями, оставаясь при этом полностью функциональным и готовым к передаче заказчику.
  • 3. Самоорганизующаяся команда. Как показывает практика, только самоорганизующиеся команды способны гибко реагировать на изменения. Дело в том, что короткие итерации и часто меняющиеся требования приводят к тому, что поддерживать документацию по проекту в полном объеме технически невозможно. В этом случае команда тратила бы на работу с требованиями больше времени, чем на разработку кода. А раз документации мало, членам команды приходится чаще общаться лицом к лицу, решая повседневные проектные задачи. Следовательно, команда должна быть самоорганизующейся, чтобы справиться с потоком проблем.
  • 4. Адаптирующийся процесс. В традиционном подходе к разработке процесс определяется на уровне организации, а на уровне проекта происходит его подгонка. На практике, как правило, это означает, что менеджер проекта принимает решение, какие из стандартных регламентных требований организации неприменимы к проекту, и формулирует свое решение в соответствующем документе. В Agile-методологиях процесс определяется по ходу проекта самой проектной командой.

Одной из самых ранних работ, повлекших за собой появление современных методов итеративной разработки, является опубликованная в 1985 г. статья Б. Боэма «Спиральная модель разработки программного обеспечения».

В начале 90-х гг. XX в. Дж. Сазерленд и К. Швабер изобрели и начали использовать в компании Easel Согр. методологию, которую они назвали Scrum (см. предыдущий раздел). Метод был основан на подходе, который применялся в таких несофтверных компаниях, как Honda, Canon и Fujitsu. Для Scrum характерны 30-дневные итерации, называемые спринтами, а также то, что повышенное внимание должно уделяться практикам по самоорганизации команд. Первая работа по Scrum была опубликована в 1999 г. [27].

В середине 90-х гг. XX в. компания Rational начала разработку методологии Rational Unified Process (унифицированный процесс Rational), в основу которой были положены итеративность и инкрементность разработки (см. раздел 3.7.6). Процесс основан на применении прецедентов использования (Use Cases) и включает набор некоторых «лучших практик» софтверной разработки на все случаи жизни.

В 1994-м группа людей, использовавших Rapid Application Development, собралась, чтобы обсудить описание стандартного итеративного процесса. Через некоторое время это описание трансформировалось в методологию DSDM (Dynamic Systems Development Method), которая в наши дни особенно популярна на ее родине - в Великобритании.

В 1996 г. к проекту Chrysler СЗ, который к тому времени уже был практически провален, присоединился К. Бек. Он вместе с Р. Джеффрисом использовал все известные ему на тот момент практики и пришел к выводу, что их совместное применение намного превышает эффект, получаемый от каждой по отдельности. Методология, названная Extreme Programming (ХР - экстремальное программирование), быстро получила широкую известность благодаря ориентации на простоту, коммуникацию и раннее тестирование, а также из-за провокационного названия.

В 1997 г. П. Коад и Дж. Люка подключились к безнадежному проекту по построению большой логистической системы и успешно справились с ним за счет применения практики итеративной разработки. Они описали свой подход к разработке в методологии Feature Driven Development (FDD).

В феврале 2001 г. 17 разработчиков методологий, авторов DSDM, ХР, Scrum, FDD и др., собрались для того, чтобы попытаться обнаружить что-нибудь общее в своих подходах. Они сформировали группу под названием Agile Alliance. Слово agile («быстрый, ловкий, стремительный») отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет. Результатом работы группы стал Манифест гибкой разработки (Agile Manifesto; http://agilemanifesto.org). Тогда же появился термин Agile (т.е. «гибкий, шустрый»), объединяющий все методологии под одной крышей.

Этот подход под названием «Быстрая разработка ПО» (Agile software development) базируется на четырех идеях, сформулированных ими в документе «Манифест быстрой разработки» (Agile Alliance's Manifesto) и заключающихся в следующем [7]:

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

Принципы, которые разъясняет Agile Manifesto [11]:

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

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

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

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

  • • С-дефекты вызывают потерю удобства;
  • • Э-дефекты вызывают потерю возместимых средств (материальных или финансовых);
  • • Е-дефекты вызывают потерю невозместимых средств;
  • • Ь-дефекты создают угрозу человеческой жизни.

Масштаб определяется количеством разработчиков, участвующих в проекте:

  • • от 1 до 6 человек - малый масштаб;
  • • от 6 до 20 человек - средний масштаб;
  • • свыше 20 человек - большой масштаб.

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

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

Существуют методологии, которые придерживаются ценностей и принципов, заявленных в Agile Manifesto. Вот некоторые из них: Agile Modeling, Agile Unified Process, Agile Data Method, DSDM, Essential Unified Process, (Extreme Programming, XP - экстремальное программирование), Feature Driven Development и др.

В некоторых статьях проводится сравнительное сопоставление этих методологий по большому диапазону критериев: жизненный цикл, роли, практики, метрики и т.п. В частности, в [21 ] предложена следующая формула для сравнения методологий: Ценности + Принципы + Практики.

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

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

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

Какой же расклад дают методологии, по мнению Д. Миллера, автора статьи [21]?

Agile Manifesto = 4 + 12 + 0;

Extreme Programming = 5+14 +24;

Scrum = 5 + 5 + 7;

Agile Modeling = 5 + 13 + 21;

Lean = 0 + 7 + 7;

Feature Driven Development = 0 + 8+16;

Adaptive Software Development = 0 + 6 + 18;

Kanban = 0 + 6 + 3;

RUP = 0 + 7+ 120.

Команда, успешно применяющая практики гибкой разработки, проходит в своем развитии следующие стадии:

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

Из приведенного на рис. 3.13 графика видно, что производительность команды на пути к действительно высоким значениям снижается. В чем причина? Это объясняется тем, что команда не может мгновенно стать высокопродуктивной, а обязательно проходит несколько последовательных фаз развития [27].

  • 1. Forming - члены команды начинают осторожно присматриваться друг к другу, они учатся работать друг с другом и пытаются понять свою роль в команде.
  • 2. Storming - по окончании разведки члены команды начинают сражаться за власть и контроль на проектом, практически никогда не соглашаются друг с другом, выражают недоверие и предубеждение. На этом этапе несколько лидеров формируют вокруг себя альянсы. Это самая тяжелая и, к сожалению, неизбежная фаза формирования команды; здесь очень важно научиться правильно управлять конфликтами.
  • 3. Norming- борьба постепенно стихает, члены команды теперь знают друг друга достаточно хорошо и начинают понемногу доверять друг другу. На совместных обсуждениях они способны достигать консенсуса и принимать командные решения.
  • 4. Performing - команда самоуправляема и наконец может отвлечься от выяснения отношений и полностью посвятить себя проекту. Члены команды полностью доверяют друг другу и чувствуют взаимную ответственность. Команда начинает действовать как один человек: она может давать обещания и выполнять их, а также способна принимать решения, руководствуясь стратегическими соображениями.

Сколько же времени может занять создание высокопроизводительной команды? Конечно, это зависит от множества факторов, в том числе и от состава команды. По мнению А. Уразбаева, автора статьи [27], процесс формирования команды занимает от трех до пяти итераций независимо от их продолжительности. Ключевые роли в достижении командой самоуправляемости в Agile играют функции менеджера проекта и кол-лаборативные практики.

Фазы развития команды

Рис. 3.13. Фазы развития команды

В Agile само понятие «менеджер проекта» трансформируется: он должен не раздавать задачи и контролировать их исполнение, а как можно быстрее превратить команду из группы разобщенных личностей в сплоченный коллектив.

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

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

Практики гибкой разработки должны помочь членам команды в их повседневной работе, но они не могут мгновенно научить их работать по-новому. Этот процесс требует времени и приложения определенных усилий. Команда должна научиться совместно работать и общаться. Наиболее важными являются следующие коллаборативные практики: ретроспектива (retrospective) и Scrum (stand-up meeting, летучка).

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

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

Внедрение Agile-методологий может быть связано с рядом трудностей. По мнению автора статьи [27], это следующие проблемы.

  • 1. Привычка кроли. Члены проектной команды поначалу неохотно соглашаются выполнять несвойственные им проектные роли, даже если понимают, что это принесет несомненную пользу проекту. Например, аналитики не любят тестировать систему, хотя именно им положено знать, как она должна работать. Проблемы такого рода легко заметны в проекте и, как правило, решаются на ретроспективах самой командой.
  • 2. Привычка к документам. Поначалу разработчики ожидают от заказчика документа требований по проекту, где будут разъяснены все вопросы. Но поскольку это не самый эффективный способ передачи информации, разработчики должны научиться работать напрямую с заказчиком. Через какое-то время работы в проекте, пообщавшись напрямую с заказчиком, разработчики смогут ориентироваться в бизнесе и решение части очевидных вопросов смогут брать на себя.
  • 3. Новая команда. Настоящей проблемой для менеджера проекта является новая команда, где рабочие отношения между людьми еще не сформировались. Люди не знают друг друга, стесняются обращаться за помощью и боятся открыто критиковать друг друга за неправильные проектные решения. Менеджер проекта должен помочь команде как можно скорее установить неформальные отношения. Очень полезными оказываются различные мероприятия по тимбилдингу, такие как совместные ужины или спортивные мероприятия.
  • 4. Проблемы с общением. К сожалению, далеко не все люди по своей природе экстраверты и способны на открытое общение. Далеко не всегда у них получается эффективно общаться друг с другом. На начальном этапе проекта проводить все собрания между членами проектной команды должен менеджер проекта, добиваясь продуктивности и эффективности.
  • 5. Давление по срокам. Заказчик требует выполнения установленных сроков. Ему необходимо вовремя получить желаемую функциональность. Задача команды состоит в том, чтобы уложиться в требуемые сроки, не принося в жертву качество продукта. В противном случае скорость разработки в долгосрочной перспективе упадет, так как стоимость изменений из-за низкого качества возрастет. Кроме того, плохое качество отрицательно влияет и на мотивацию внутри проектной команды. Задача менеджера проекта - постоянно напоминать команде и заказчику о необходимости поддерживать высокое качество.
  • 6. Креативность. Не все задачи в проекте одинаково интересны. Разработчикам часто хочется принимать проектные решения, которые идут в ущерб проекту, но оригинальны в техническом плане. Тут важно помнить о принципах KISS (keep it simple) и YAGNI (you ain’t gonna need it). Проектные решения должны быть простыми. Не стоит делать то, что не является абсолютно необходимым в обозримом промежутке времени. Как же научить команду принимать простые решения? Может быть, полезно разрешить команде ошибиться один раз и затем на ретроспективе разобрать пример, чтобы разработчики сделали вывод на буду-

щее? Практически в любом проекте время от времени возникают исследовательские задачи (новые технологии, новые технические области знаний). Именно здесь место для всяких проб и экспериментов.

  • 7. Оценка времени. При оценке сроков на выполнение задачи разработчики часто забывают, что, помимо написания кода, в задачу как минимум входят дизайн и тестирование. По этой причине в начале проекта программисты часто переоценивают свою производительность. На ретроспективах эти ошибки отмечаются и делаются выводы на будущее. Впоследствии команда учится правильно оценивать свои возможности и со временем (через три-четыре итерации) точность установления сроков растет наряду с производительностью.
  • 8. Проблема с менеджментом. Менеджмент ожидает получения определенной функциональности к определенному сроку. Но Agile-методология не может гарантировать 100%-го выполнения планов. Можно лишь ожидать, что высокоприоритетные требования будут реализованы в первую очередь. Полезно согласовывать с менеджментом планы на уровне релизов. Высокоуровневость плана релиза позволяет менеджеру продукта в достаточно широких пределах варьировать объем разработки даже на уровне отдельных функций системы. Например, в задачу разработки подсистемы поиска можно включить учет морфологии, а можно на нем и сэкономить.
  • 9. Проблемы с некомандным поведением. При внедрении Agile иногда возникает следующая ситуация. Во время совещания вдруг кто-то вскакивает со своего места и начинает предлагать те или иные идеи. Возражения он с ходу отметает и навязывает собственное решение. Через некоторое время он заявляет, что решение принято и пора перейти ко второму вопросу. Разумеется, команда никакого решения не принимала, его принял этот человек.

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

 
<<   СОДЕРЖАНИЕ   >>