Внедрение Agile

Асхат Уразбаев

Влияние неопределенности и изменений

И тут на помощь приходят… гибкие методологии

Самоорганизация в Agile

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

Менеджер проекта в Agile

Коллаборативные практики

Проблемы при внедрении Agile

Переход проектных команд на гибкие методы разработки позволяет компаниям достичь многих очевидных преимуществ. В настоящее время наиболее актуальными темами для обсуждения становятся способы облегчить этот переход как для компании, так и для отдельных проектных команд.

Влияние неопределенности и изменений

В компании Luxoft существует чрезвычайно полезная практика: по окончании проекта менеджер пишет отчет, в котором излагает проблемы и найденные решения. Такой отчет называется post mortem report. Чтение «посмертных отчетов» — занятие весьма увлекательное. Менеджеры проектов обнаруживают поразительную изобретательность в преодолении трудностей, борьбе с капризами заказчика и не до конца отлаженными технологиями. Причины возникающих проблем могут быть разными: неизвестные или плохо знакомые технологии, недооценка сроков и бюджета работ, человеческий фактор — несоответствие квалификации отдельных исполнителей роли в проекте. Зачастую заказчик не знает, что именно ему нужно, и постоянно меняет требования; бывает, что в ходе проекта меняется менеджер проекта со стороны заказчика, и т.д.

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

Первая и самая главная — выполнять все это в полном объеме довольно дорого. Поэтому на практике делается только малая часть из всего перечисленного.

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

И тут на помощь приходят… гибкие методологии

Гибкие методологии построены таким образом, что изменения приветствуются, а неопределенность признается. 

Существует несколько отличительных признаков всех гибких методологий:

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

Самоорганизация в Agile

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

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

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

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

Внедрение коллаборативного мышления в организации, управляемой традиционными административными методами, требует особого мужества. Все менеджеры здесь достигли своего положения благодаря умению брать ответственность на себя и способности единолично принимать правильные решения. Как перебороть представление о том, что такое хорошо и что такое плохо, и начать внедрять демократию в отдельно взятом проекте? Зачастую решения о внедрении Agile-методологии принимаются чисто административными методами: находится ответственный, которому поручается команда. Стараясь быть эффективным, менеджер щедро раздает пинки и тычки, кровью выбивая из команды «мотивированность» на успех. Такая тактика не принесет ничего, кроме разочарования. Команда не сумеет принимать решения самостоятельно, а значит, не будет нести ответственность за него.

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

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

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

Из приведенного на рисунке графика видно, что производительность команды на пути к действительно высоким значениям снижается. В чем причина?

 Это объясняется тем, что команда не может мгновенно стать высокопродуктивной, а обязательно проходит несколько последовательных фаз развития:

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

Теперь становится понятно, почему некоторые Agile-проекты имеют проблемы на самом старте — они не могут преодолеть стадию Storming.

Такая проблема действительно возникла в одном из наших первых Agile-проектов в компании Luxoft. Прочитав пару статей и не очень хороших книжек, посвященных этой тематике, мы решили внедрить Agile в жизнь. Рассказав новообразованной команде, что она теперь самоорганизующаяся (про это было рассказано в книжке), менеджер проекта стал ждать грамотных технических решений и слаженной работы. Однако эта команда почему-то никак не могла принять хоть какое-то решение на совместных совещаниях. Увидев неизбежную неразбериху в проекте на самом его старте, трудно было не испугаться и не попытаться вернуть все на исходную позицию, превратив команду в working group с приемлемой (и все же достаточно низкой!) производительностью.

Фазы развития команды (из книги: Katzenbach J. The wisdom of teams:
Creating High Performance Organizations)

Сколько же времени может занять создание высокопроизводительной команды? Конечно, это зависит от множества факторов, в том числе и от состава команды. Мне кажется, процесс формирования команды занимает от трех до пяти итераций независимо от их продолжительности.

Ключевые роли в достижении командой самоуправляемости в Agile играют функции менеджера проекта и коллаборативные практики.

Менеджер проекта в Agile

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

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

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

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

Коллаборативные практики

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

Наиболее важными являются следующие коллаборативные практики.

Ретроспектива (retrospective)

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

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

SCRUM (stand-up meeting, летучка) 

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

Проблемы при внедрении Agile

Привычка к роли

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

Привычка к документам

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

Новая команда

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

Проблемы с общением

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

Давление по срокам

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

Креативность

Не все задачи в проекте одинаково интересны. Разработчикам часто хочется принимать проектные решения, которые идут в ущерб проекту, но оригинальны в техническом плане. Тут важно помнить о принципах KISS (keep it simple) и YAGNI (you ain’t gonna need it). Проектные решения должны быть простыми. Не стоит делать то, что не является абсолютно необходимым на обозримом промежутке времени. Как же научить команду принимать простые решения? Может быть, полезно разрешить команде ошибиться один раз и затем на ретроспективе разобрать пример, чтобы разработчики сделали вывод на будущее? 

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

Оценка времени

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

Проблема с менеджментом

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

Проблемы с некомандным поведением

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

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

КомпьютерПресс 5'2007