Внедрение Agile
| November 15, 2006 | Posted by Denis under Практики, Статьи |
Переход проектных команд на гибкие методы разработки позволяет компаниям достичь многих очевидных преимуществ. В настоящее время наиболее важными темами для обсуждения становятся способы облегчить этот переход как для компании так и для отдельных проектных команд.
Влияние неопределенности и изменений
В нашей компании есть чрезвычайно полезная практика – по окончании проекта менеджер пишет отчет, в котором он описывает проблемы и найденные решения. Такой отчет называется post mortem report. Чтение посмертных отчетов занятие чрезвычайно увлекательное.
Менеджеры проектов обнаруживают поразительную изобретательность в преодолении трудностей, борьбе с происками заказчика и глючными технологиями. Причины проблем всякий раз разные: неизвестные или незнакомые технологии; недооценка сроков и бюджета работ; человеческий фактор –несоответствие квалификации отдельных личностей заявленной роли. Часто заказчик не знает чего он хочет и постоянно меняет требования, бывает, что в ходе проекта меняется менеджер проекта со стороны заказчика.
Я не пытаюсь никого обвинить в некомпетентности. Эти проблемы на самом деле типичны для нашей индустрии. Так уж случилось, что мы работаем в условиях высокой неопределенности и постоянных изменений. Методы борьбы с проблемами известны и широко применяются с переменным успехом. Менеджеры проектов управляют рисками, изменениями, требованиями, конфигурацией, ожиданиями заказчика и т.д. Если все это правильно выполнять, можно более или менее гарантировать относительно безбедное существование до конца проекта.
Впрочем, тут есть несколько сложностей.Первая и самая главная – делать все эти вещи в полном объеме занятие довольно-таки дорогое. Именно поэтому на практике делается только малая часть из всего перечисленного. Вторая проблема – для заказчика это не то чтобы приятно. Когда он придет к вендору с пожеланием к своей системе, нужной ему для автоматизации его реальных бизнес нужд, ему объяснят, что то, что он хочет – это запрос на изменение, его оценка потребует много времени, а исполнение еще больше и что сроки проекта при этом увеличатся. Заказчик может бы и обменял новую функциональность на ставшую ненужной старую, но этой опции ему никто не предоставит. Работы ведутся, требования утверждены, код в разработке или частично сделан – поздно пить боржоми. Такое поведение трудно назвать «ориентированным на заказчика»
И тут на помощь приходят они…гибкие методологии
Гибкие методологии построены таким образом, что изменения приветствуются, а неопределенность признается. Существует несколько отличительных признаков всех гибких методологий.
- Разработка ведется короткими итерациями. Чем короче итерация, чем чаще можно демонстрировать продукт заказчику и изменять направление развития продукта. Заказчик сможет руководить разработкой продукта вместо того, чтобы дождаться окончания разработки и убедиться, что получилось совсем не то, что он хотел.
- Инкрементальная разработка. За каждую итерацию продукт дополняется новыми функциями, оставаясь при этом полностью функциональным и готовым к передаче заказчику
- Самоорганизующаяся команда. Как показывает практика, только самоорганизующиеся команды способны гибко реагировать на изменения. Дело в том, что короткие итерации и часто меняющиеся требования приводят к тому, что поддерживать документацию по проекту в полном объеме невозможно технически. В этом случае команда тратила бы на работу с требованиями больше времени, чем на разработку кода. А раз документации мало – команде приходится намного больше общаться лицом к лицу, решая повседневные проектные задачи. Команда должна быть самоорганизующейся, чтобы справится с потоком проблем.
- Адаптирующийся процесс. В традиционном подходе к разработке процесс определяется на уровне организации, а на уровне проекта происходит его тейлоринг, «подгонка по телу проекта». На практике это означает, как правило, что менеджер проекта принимает решения, какие из стандартных регламентных требований организации не применимы к проекту и документирует свое решение в соответствующем документе. В Agile процесс определяется по ходу проекта самой проектной командой.
Принципы Agile изменяют представление о том, как надо разрабатывать программное обеспечение. Трансформируется сама парадигма: фокус смещается с ориентированности на процесс как на последовательность заранее продуманных руководством шагов на ориентированность на проектную команду, как на группу людей, способных самоорганизоваться и решать все проблемы самостоятельно. Это изменение носит совсем не формальный характер: оно требует от членов проектных команд совершить переворот в собственном сознании, отказаться от ориентированности на административно-командные методы управления и попытаться сформировать совершенно новые для них методы решения проблем.
По сути Agile – набор практик, которые позволяют воплощать все эти принципы в жизнь.Некоторые принципы и связанные с ними практики просты и практически никогда не вызывают трудностей при внедрении. Речь идет прежде всего об итеративной и инкрементальной разработке. Сокращение длины итерации до месяца и меньше принимается руководством с удовольствием, да и разработчики не видят в этом ничего непонятного или странного.
Куда сложнее дело обстоит с принципами самоорганизации команды и адаптирующегося процесса. Agile особенно эффективен, если команда самоуправляема и самоорганизуема. Добиться этого на практике непросто. Фактически, это означает смену парадигмы мышления – с привычки подчинения на привычку сотрудничества. Препятствует процессу внедрения, например, индивидуальная оценка деятельности каждого члена команды, принятая во многих организациях. Нет ничего более опасного для воспитания команды, чем осуждение отдельного члена команды. Виноватый настраивается не на сотрудничество, а на самозащиту. Все Agile методологии подчеркивают, что оценивать производительность можно только для команды целиком.
Внедрение коллаборативного мышления требует особого мужества в организации, управляемой традиционными административными методами. Все менеджеры достигли своего положения благодаря тому, что знают, что такое личная ответственность и способны принимать правильные решения в одиночестве. Как теперь перебороть представление о том, что такое хорошо и что такое плохо и начать внедрять “демократию” в отдельно взятом проекте? Зачастую решения о внедрении Agile принимаются чисто административными методами – находится отсветственный, ему поручается команда. Стараясь быть эффективным, менеджер щедро раздает пинки и тычки, кровью выбивая из команды “мотивированность” на успех. Такая тактика не принесет ничего, кроме разочарования. Команда не умеет принимать решения самостоятельно – а значит и не несет за решение ответственность.
Фазы развития команды
Команда, которая на практике успешно применяет практики гибкой разработки проходит в своем развитии стадии
- рабочей группы, руководимой менеджером
- псевдокоманды
- потенциальной команды
- продуктивной команды
Если вы посмотрите на график, то заметите, что производительность команды на пути к по-настоящему высоким значениям снижается. В чем причина?
(Из книги J.Katzenbach, The wisdom of teams: Creating High Performance Organizations)
Команда не может мгновенно стать высокопродуктивной. Она обязательно проходит через несколько последовательных фаз развития:
- Forming. Члены команды начинают осторожно присматриваться друг к другу. Они учатся работать друг с другом и пытаются понять свою роль в команде
- Storming. После окончания разведки члены команды начинают сражаться за власть и контроль на проектом. Они практически никогда не могут согласится с друг другом, выражают недоверие и предубеждение. На этом этапе несколько лидеров формируют вокруг себя альянсы. Эта самая тяжелая, но к сожалению, неизбежная фаза формирования команды. Очень важно на этом этапе правильно управлять конфликтами
- Norming. Борьба постепенно заканчивается, члены команды тепеь знают друг друга достаточно хорошо и начинают понемногу доверять друг другу. На совместных обсуждениях они способны достигать консенсуса и принимать командные решения.
- Performing. Команда самоуправляема и наконец может отвлечься от выяснения отношения и полностью посвятить себя проекту. Члены команды полностью доверяют друг другу и чувствуют ответственность друг перед другом. Команда начинает действовать как один человек: она может давать обещания и выполнять их. Она способна принимать решения руководствуясь стратегическими соображениями
Теперь становится понятно, почему некоторые Agile проекты имели проблемы на самом старте – они не смогли преодолеть стадию «Storming». Такая проблема действительно возникла в одном из наших первых Agile проектов в Компании. Прочитав пару статей и не очень хороших книжек, мы решили внедрить Agile в жизнь. Рассказав новообразованной команде, что она теперь самоорганизующаяся (про это было в книжке) менеджер проекта стал ждать грамотных технических решений и слаженной работы. Однако команда почему-то никак не могла принять хоть какое-то решение на совместных митингах. Понаблюдав неизбежный бардак в проекте на самом его старте, трудно было не испугаться и не попытаться вернуть все в исходное русло, превратив команду в working group с приемлемой (и все же достаточно низкой!) производительностью.
Сколько же времени может занять создание высокопроизводительной команды? Конечно, это зависит от множества факторов, в том числе и от состава команды. Мне кажется, процесс формирования команды занимает от трех до пяти итераций вне зависимости от их длины.Ключевые роли в достижении командой самоуправляемости в Agile играют функции менеджера проекта и коллаборативные практики
Менеджер проекта в Agile
В Agile само понятие менеджера проекта трансформируется. Его роль не раздавать задачи и контролировать их исполнение, а как можно быстрее превратить команду из группы разобщенных личностей в спаянный коллектив. Менеджер проекта отвечает за создание атмосферы доверия в команде, налаживает коммуникации внутри команды, устраняет внешние препятствия. Роль менеджера проекта особенно важна на первых, самых опасных фазах формирования команды. Он должен участвовать во всех проектных митингах, помогать команде ставить перед собой цели и последовательно добиваться их исполнения, должен правильно управлять неизбежными конфликтами и напоминать команде о принятых решениях. Его роль – фасилитатор общения и собственник процесса. Он облегчает и ускоряет процесс самоорганизации, налаживая коммуникации внутри команды.
Менеджер также отвечает за соблюдение практик гибкой разработки в проекте, поскольку именно отказ от практик часто бывает причиной трудностей через некоторое время. Не позволять инертности мышления в команде взять вверх Менеджер проекта делает видимыми все проблемы и открытые вопросы – как внутри команды, так и по отношению к заказчику и заинтересованным лицам извне проекта
Пожалуй, самым близким аналогом в традиционном подходе является Process Engineer. Разница в том, что работает он на уровне проекта, а не организации. Колаборативные практикиПрактики гибкой разработки должны помочь членам команды в их повседневной работе в гибком окружении, но они не могут мгновенно научить их работать по-новому.
Этот процесс требует времени и приложения определенных усилий. Команда должна научится работать и общаться совместно.Наиболее важными практиками являются следующие коллаборативные практики: Ретроспектива (retrospective).Каждый раз по окончании итерации команда собирается и обдумывает результаты итерации. Все, что мешало продуктивной работе или далало ее неэффективной, выносится на обсуждение. Предлагаются различные способы решения проблемы, выбираются лучшие. По сути, это механизм создания процесса на уровне проекта. Различие по сравнению с традиционными методологиями состоит в том, что автором процесса является сама команда, а не внешние специалисты, не разбирающиеся в проектной специфике.
Кроме того, ретроспектива – это инструмент самоорганизации команды. На рестроспективе команда обращает внимание не только на технические, конфигурационные или иные процессные проблемы. Речь может зайти, например, о неготовности или неспособности отдельных членов проектной команды помогать остальным. Чтобы обсуждение было полезным, все принятые решения должны фиксироваться менеджером и затем претворятся в жизнь.
SCRUM (stand up meeting, летучка).
Ежедневный 15-минутный митинг. Каждый член команды рассказывает, что делал вчера, что будет делать сегодня, и что ему мешает или не хватает для продуктивной работы. Этот митинг нужен для синхронизации работы команды, а не для сбора статусов для последующего доклада руководству. Scrum это и механизм самоорганизации: каждый член команды должен знать, что происходит в проекте с тем, чтобы помочь всей команде добиваться нужных результатов. Он может высказать свое мнение по открытым вопросам или вызваться помочь отстающему коллеге. Короткая длительность этого митинга очень важна. Все вопросы, требующие длительного обсуждения, выносятся за его пределы.
Проблемы при внедрении Agile
Привычка к роли
Члены проектной команды поначалу неохотно соглашаются выполнять работы, не свойственные привычным для них проектным ролям, даже если они понимают, что это принесет несомненную пользу проекту. Например, аналитики не любят тестировать систему, хотя кому как не им знать, как она должна работать. Проблемы такого рода легко заметны в проекте, и, как правило, решаются на рестроспективах самой командой
Привычка к документам
Поначалу разработчики ожидают от заказчика документа требований по проекту, где будут разъяснены все вопросы. Это не самый эффективный способ передачи информации и разработчики должны научиться работать напрямую с заказчиком. Через какое то время работы в проекте, пообщавшись напрямую с заказчиком, разработчики смогут ориентироваться в бизнесе и решение части очевидных вопросов смогут брать на себя. Даже если они допустят ошибку, она будет замечена заказчиком в конце итерации и затем исправлена.
Новая команда
Настоящим вызовом для менеджера проекта является новая команда, где рабочие отношения между людьми еще не сформировались. Люди не знают друг друга, стесняются обращаться за помощью и боятся открыто критиковать друг друга за неправильные проектные решения. Менеджер проекта должен помочь команде как можно скорее установить неформальные отношения друг с другом. Очень полезными оказываются различные мероприятия по тимбилдингу, такие как совместные походы в рестораны или спортивные мероприятия.
Проблемы с общением
К сожалению, далеко не все люди являются экстравертами и способны на открытое общение. Далеко не всегда они способны эффективно общаться друг с другом. На начальном этапе проекта менеджер проекта должен проводить все митинги с между членами проектной команды, добиваясь продуктивности и эффективности.
Давление по срокам
Заказчик оказывает давление по срокам. Ему необходимо получить желаемую функциональность как можно скорее. Задача команды состоит в том, чтобы по возможности выполнить его, не принося в жертву качество продукта. В противном случае скорость разработки в долгосрочной перспективе упадет, так как стоимость изменений из-за низкого качества станет высокой. Кроме того, плохое качество отрицательно влияет и на мотивацию внутри проектной команды. Задача менеджера проекта – постоянно напоминать команде и заказчику необходимости поддерживать высокое качество.
Креативность
Не все задачи в проекте одинаково интересны. Разработчикам часто интересно принимать проектные решения, которые идут в ущерб проекту, но интересны с технической точки зрения. Тут важно помнить о принципах KISS (keep it simple) и YAGNI (you ain’t gonna need it). Проектные решения должны быть простыми. Не стоит делать то, что не является абсолютно необходимым на обозримом промежутке времени. Как же научить команду принимать простые решения? Автору показалось полезным дать команде ошибиться один раз и затем разобрать пример на ретроспективе с тем чтобы разработчики сделали вывод на будущее.
Практически в любом проекте время от времени возникают исследовательские задачи (новые технологии, новые технические области знаний). Именно здесь место для всяких проб и экспериментов.
Оценка времени
При оценке времени на выполнение задачи разработчики часто забывают, что помимо написания кода в задачу как минимум входит дизайн и тестирование. По этой причине в начале проекта программисты часто переоценивают свою производительность. На рестроспективах эти ошибки отмечаются и делаются выводы на будущее. В длительной перспективе команда учится делать правильные оценки и со временем (через 3-4 итерации) точность растет наряду с самой производительностью.
Проблема с менеджментом.
Менеджмент ожидает наличия определенной функциональности к определенному сроку. Но agile не может гарантировать стопроцентного выполнения планов. Можно лишь ожидать, что высокоприоритетные требования будут реализованы в первую очередь. Полезно согласовывать с менеджментом планы на уровне релизов. Высокоуровневость плана релиза позволяет менеджеру продукта в достаточно широких пределах варьировать объем разработки даже на уровне отдельных функций системы. Например, в задачу разработки подсистемы поиска можно включать учет морфологии, а можно и сэкономить на нем.
Проблемы с некомандным поведением
При внедрении Agile иногда можно наблюдать следующую ситуацию. Во время митинга вдруг кто-то один вскакивает со своего места и начинает предлагать какие-то идеи. Возражения он сходу отметает и начинает вести митинг. Через некоторое время он заявляет, что решение принято и пора перейти ко второму вопросу. Разумеется, команда никакого решения не принимала. Фактически, этот человек принял решение за команду, играя против нее.
Тут возможны разные варианты. Конечно, может быть этот человек просто увлекся и через некоторое время придет в себя. Но есть и люди, которые просто в силу своих человеческих качеств неспособны играть в команде. Agile полагается на способность людей договариваться друг с другом и умение решать проблемы в личном общении. Если этих качеств у человека нет, то можно с сожалением констатировать, что Agile ему не подходит и с таким человеком лучше расстаться.
