Файл: Инфрам.pdf

118 коммуникацию и раннее тестирование, а также из-за провокационного названия.
В 1997 году Питер Коад и Джефф Де Люка подключились к безна- дежному проекту по построению большой логистической системы и успешно справились с ним за счет применения практики итеративной разработки. Они описали свой подход к разработке в методологии
Feature Driven Development (FDD).
В феврале 2001 года 17 разработчиков методологий, авторов DSDM,
XP, Scrum, FDD и др., собрались для того, чтобы попытаться обнару- жить что-нибудь общее в своих подходах. Они сформировали группу под названием Agile Alliance. Слово agile (быстрый, ловкий, стреми- тельный) отражало в целом их подход к разработке ПО, основанный на богатом опыте участия в разнообразных проектах в течение многих лет.
Результатом работы группы стал Манифест гибкой разработки (Agile
Manifesto; http://agilemanifesto.org). Тогда же появился термин Agile (то есть гибкий, шустрый), объединяющий все методологии под одной крышей.
Этот подход под названием "Быстрая разработка ПО" (Agile software development) базируется на четырех идеях, сформулированных ими в документе "Манифест быстрой разработки ПО" (Agile Alliance's
Manifesto) и заключающихся в следующем [7]: индивидуумы и взаимодействия между ними ценятся выше процес- сов и инструментов; работающее ПО ценится выше всеобъемлющей документации; сотрудничество с заказчиками ценится выше формальных догово- ров; реагирование на изменения ценится выше строгого следования пла- ну.
Принципы, которые разъясняет Agile Manifesto [11]: удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО; приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта); частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протя- жении всего проекта; проектом занимаются мотивированные личности, которые обеспече- ны нужными условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации – личный разговор
(лицом к лицу); работающее ПО – лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок; постоянное внимание на улучшение технического мастерства и удобный дизайн;

119 простота – искусство НЕ делать лишней работы; лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; постоянная адаптация к изменяющимся обстоятельствам.
При таком подходе технология занимает в процессе создания ПО вполне определенное место. Она повышает эффективность деятельно- сти разработчиков при наличии любых из следующих четырех условий: технология позволяет людям легче выразить свои мысли; она выполняет задачи, невыполнимые вручную; технология автоматизирует утомительные и подверженные ошибкам действия; облегчает общение между людьми.
При этом следует четко понимать: при всех достоинствах быстрой разработки ПО этот подход не является универсальным и применим только в проектах определенного класса. Для характеристики таких проектов А. Коберн ввел два параметра – критичность и масштаб. Кри- тичность определяется последствиями, вызываемыми дефектами в ПО, ее уровень может иметь одно из четырех значений:
C-дефекты вызывают потерю удобства;
D-дефекты вызывают потерю возместимых средств (материальных или финансовых);
E-дефекты вызывают потерю невозместимых средств;
L-дефекты создают угрозу человеческой жизни.
Масштаб определяется количеством разработчиков, участвую- щих в проекте: от 1 до 6 человек – малый масштаб; от 6 до 20 человек – средний масштаб; свыше 20 человек – большой масштаб.
По оценке Коберна, быстрая разработка ПО применима только в проектах малого и среднего масштаба с низкой критичностью (C или
D). Общие принципы оценки технологий в таких проектах заключаются в следующем: интерактивное общение лицом к лицу - это самый дешевый и быст- рый способ обмена информацией; избыточная "тяжесть" технологии стоит дорого; более многочисленные команды требуют более "тяжелых" и фор- мальных технологий; большая формальность подходит для проектов с большей критично- стью; возрастание обратной связи и коммуникации сокращает потребность в промежуточных и конечных продуктах; дисциплина, умение и понимание противостоят процессу, формаль- ности и документированию; потеря эффективности в некритических видах деятельности вполне допустима.

120
Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto. Вот некоторые из них: Agile
Modeling, Agile Unified Process, Agile Data Method, DSDM, Essential Uni- fied 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 графика видно, что производитель- ность команды на пути к действительно высоким значениям снижается.

121
В чем причина? Это объясняется тем, что команда не может мгновенно стать высокопродуктивной, а обязательно проходит несколько последо- вательных фаз развития [27]:
Forming – члены команды начинают осторожно присматриваться друг к другу, они учатся работать друг с другом и пытаются понять свою роль в команде;
Storming – по окончании разведки члены команды начинают сра- жаться за власть и контроль на проектом, практически никогда не со- глашаются друг с другом, выражают недоверие и предубеждение. На этом этапе несколько лидеров формируют вокруг себя альянсы. Это самая тяжелая и, к сожалению, неизбежная фаза формирования команды
– здесь очень важно научиться правильно управлять конфликтами;
Norming – борьба постепенно стихает, члены команды теперь зна- ют друг друга достаточно хорошо и начинают понемногу доверять друг другу. На совместных обсуждениях они способны достигать консенсуса и принимать командные решения;
Performing – команда самоуправляема и, наконец, может отвлечься от выяснения отношении и полностью посвятить себя проекту. Члены команды полностью доверяют друг другу и чувствуют взаимную ответ- ственность. Команда начинает действовать, как один человек: она мо- жет давать обещания и выполнять их, а также способна принимать ре- шения, руководствуясь стратегическими соображениями.
Сколько же времени может занять создание высокопроизводитель- ной команды? Конечно, это зависит от множества факторов, в том числе и от состава команды. По мнению А. Уразбаева, автора статьи [27], процесс формирования команды занимает от трех до пяти итераций не- зависимо от их продолжительности. Ключевые роли в достижении ко- мандой самоуправляемости в Agile играют функции менеджера проекта и коллаборативные практики.
Рис. 3.13. Фазы развития команды (из книги: Katzenbach J. The wis- dom of teams: Creating High Performance Organizations)
В Agile само понятие менеджера проекта трансформируется – он должен не раздавать задачи и контролировать их исполнение, а как

122 можно быстрее превратить команду из группы разобщенных личностей в сплоченный коллектив.
Менеджер проекта отвечает за создание атмосферы доверия, нала- живает коммуникации внутри команды, устраняет внешние препятст- вия. Роль менеджера проекта особенно важна на первых, самых опас- ных фазах формирования команды. Он должен участвовать во всех про- ектных совещаниях, помогать команде ставить перед собой цели, и по- следовательно добиваться их исполнения, правильно управлять неиз- бежными конфликтами и напоминать команде о принятых решениях.
Его роль – помощник общения и хозяин процесса. Он облегчает и уско- ряет процесс самоорганизации, налаживая коммуникации внутри ко- манды.
Менеджер также отвечает за соблюдение практик гибкой разработки в проекте, поскольку именно отказ от них создает через некоторое вре- мя особые трудности. Менеджер проекта делает видимыми все пробле- мы и открытые вопросы – как для команды, так и для заказчика и дру- гих заинтересованных лиц, имеющих отношение к проекту. Пожалуй, самым близким аналогом в традиционном подходе является Process
Engineer – разница лишь в том, что работает он на уровне проекта, а не организации.
Практики гибкой разработки должны помочь членам команды в их повседневной работе, но они не могут мгновенно научить их работать по-новому. Этот процесс требует времени и приложения определенных усилий. Команда должна научиться совместно работать и общаться.
Наиболее важными являются следующие коллаборативные практики. К этим практикам относятся: Ретроспектива (retrospective) и SCRUM
(stand-up meeting, летучка).
Каждый раз по окончании итерации команда собирается и обсуждает полученные результаты. Все, что мешало продуктивной работе или де- лало ее неэффективной, выносится на рассмотрение. Предлагаются раз- личные способы решения проблемы, из которых выбираются лучшие.
По сути, это механизм создания процесса на уровне проекта. Различие по сравнению с традиционными методологиями заключается в том, что автором процесса является сама команда, а не внешние специалисты, не разбирающиеся в проектной специфике. Кроме того, ретроспектива – это инструмент самоорганизации команды. В ходе ретроспективы ко- манда обсуждает только технические, конфигурационные или иные процессные проблемы – речь может зайти, например, о неготовности или неспособности отдельных членов проектной команды помогать ос- тальным.
SCRUM – это ежедневное 15-минутное собрание. Каждый член ко- манды рассказывает, что делал вчера, что будет делать сегодня, что ему мешает и чего не хватает для продуктивной работы. Это собрание нуж- но для синхронизации работы команды, а не для сбора статусов для по- следующего доклада руководству. Scrum – это и механизм самооргани- зации: каждый член команды должен знать, что происходит в проекте, с тем чтобы помочь всей команде добиваться нужных результатов. Он

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

124 it). Проектные решения должны быть простыми. Не стоит делать то, что не является абсолютно необходимым на обозримом промежутке време- ни. Как же научить команду принимать простые решения? Может быть, полезно разрешить команде ошибиться один раз и затем на ретроспек- тиве разобрать пример, чтобы разработчики сделали вывод на буду- щее? Практически в любом проекте время от времени возникают иссле- довательские задачи (новые технологии, новые технические области знаний). Именно здесь место для всяких проб и экспериментов.
7. Оценка времени. При оценке сроков на выполнение задачи разра- ботчики часто забывают, что, помимо написания кода, в задачу, как ми- нимум, входит дизайн и тестирование. По этой причине в начале проек- та программисты часто переоценивают свою производительность. На ретроспективах эти ошибки отмечаются и делаются выводы на будущее.
Впоследствии команда учится правильно оценивать свои возможности и со временем (через 3-4 итерации) точность установления сроков растет наряду с производительностью.
8. Проблема с менеджментом. Менеджмент ожидает получения оп- ределенной функциональности к определенному сроку. Но Agile- методологии не может гарантировать стопроцентного выполнения пла- нов. Можно лишь ожидать, что высокоприоритетные требования будут реализованы в первую очередь. Полезно согласовывать с менеджментом планы на уровне релизов. Высокоуровневость плана релиза позволяет менеджеру продукта в достаточно широких пределах варьировать объем разработки даже на уровне отдельных функций системы. Например, в задачу разработки подсистемы поиска можно включить учет морфоло- гии, а можно на нем и сэкономить.
9. Проблемы с некомандным поведением. При внедрении Agile ино- гда возникает следующая ситуация. Во время совещания вдруг кто-то вскакивает со своего места и начинает предлагать те или иные идеи.
Возражения он сходу отметает и навязывает собственное решение. Че- рез некоторое время он заявляет, что решение принято и пора перейти ко второму вопросу. Разумеется, команда никакого решения не прини- мала – его принял этот человек.
Тут возможны разные варианты. Может быть, этот человек просто увлекся и через некоторое время придет в себя. Но есть люди, которые просто в силу своих человеческих качеств неспособны работать в ко- манде. Agile полагается на способность людей договариваться друг с другом и уметь решать проблемы в личном общении. Если этих качеств у человека нет, то можно с сожалением констатировать, что Agile ему не подходит и с ним лучше расстаться.
3.7.10. Управление жизненным циклом приложений.
Интегрированная среда поддержки создания программных систем
Разработка ПО является довольно сложным предприятием. Создание программного продукта с достаточно четко определенными характери- стиками, выполненное с приемлемым качеством, в рамках отведенного