Задача масштабирования agile
| June 6, 2007 | Posted by Denis under Практики, Статьи |
Перевод Главы из книги Dean Leffingwell “Scaling Software Agility. Best practices for Large Enterprises”.
Препятствия во внедрении гибкой разработки на уровне компании исходят из двух источников: явные ограничения самих методов и барьеры, существующие внутри компании. Чтобы достигнуть гибкости на уровне компании, преодолеть придется оба препятствия.
Применяя то, что мы уже изучили о гибкой разработке, в последующих разделах мы рассмотрим наилучшие практики agile, позволяющие масштабирование на уровне компании. Для компании весьма удобно, что при развертывании даже небольшого количества гибких команд, применяющих лучшие практики разработки, существенно совершенствуются эффективность работы и удовлетворенность заказчика на локальном уровне команд.
Тем не менее, в масштабе компании задача извлечения максимальной пользы от гибких методов весьма серьезна, и потому CIO, вице-президенты и другие ключевые люди в компании должны понимать, что внутри компании должны быть решены весьма серьезные организационные задачи.
В действительности многие компании, успех которых зависит от разработки программного обеспечения, с некоего момента теряют производительность. По мере развития компании вместе с ней развиваются организационные паттерны, политики и процедуры. К сожалению некоторые из них, а часто – весьма большое число, двигаются в противоположную сторону по отношению к гибким методам. Эти паттерны созданы для сопротивления каким-либо изменениям. А ведь именно изменения раскрывают креативную мощь и продуктивность профессиональных разработчиков.
Более того, когда дело доходит до масштабирования agile в рамках компании, появляются два класса серьезных задач. Первый обусловлен присущими самой гибкой разработке трудностями – представляет собой явные ограничения из-за фиксированного набора правил и допущений, заложенных в основу гибких методов.
Явные ограничения в самом методе.
Основная идея этой книги состоит в том, что с помощью изменения и адаптации agile действительно масштабируется на уровне компании. Тем не менее, факт остается фактом, что эти методы были разработаны и систематизированы для небольших команд, где всегда подразумевалась полная свобода для исследований и инноваций и где все необходимые команде ресурсы, равно как и большинство возникающих проблем могли быть решены на уровне одной команды.
Дополнительно следует признать, что множество успешных применений этих методов на сколько-нибудь более широком масштабе (десятки разработчиков, использующих Scrum, XP и т.д.) имели место в случае множества небольших и до определенной степени независимых проектов внутри компании, где каждый отдельный проект весьма хорошо подходил для гибкой разработки и остальная деятельность компании была по большому счету малозависимой от компонент, подсистем, функций, разрабатываемых этими гибкими командами.
Эти приложения могли быть небольшими независимыми продуктами, либо приложениями для пользования внутри компании, или, скажем, фронт-эндами для так называемых унаследованных (legacy) систем; однако, в любом случае они представляли собой относительно изолированные сегменты, не требующие активного координирования большого числа людей, команд или отделов.
Небольшой размер команды
В XP и Scrum рекомендуются команды, состоящие из не более восьми человек, включая владельца продукта/менеджера продукта или прокси заказчика, разработчиков и тестеров. В большинстве случаев команды считают, что даже такое количество является слишком большим и, соответственно, делятся на команды по компонентам или функциональности системы, состоящими из трех-пяти человек. Для компании, собирающейся развернуть гибкую разработку, скажем, на 1000 человек, одна лишь мысль об управлении сотнями команд пугает не на шутку и возникает актуальная потребность понять, каким образом подогнать новую модель разработки под существующую организационную иерархию.
Заказчик как неотъемлемая часть команды
Мы были свидетелями успеха XP (в частности) в большом числе ИТ-подобных сред, где заказчик находился в буквальном смысле слова в “кабинете напротив”, а работавший с командой бизнес аналитик участвовал в столь необходимых подробных рассмотрениях историй пользователя и приемочных тестов. Тем не менее, это далеко не так в большинстве организаций: заказчик является удаленным или же не обладает необходимыми навыками или временем, чтобы принимать такое плотное участие в разработке. Если, например, компания является большим независимым производителем (ISV), то у приложения будут десятки тысяч пользователей и не будет одного-единственного заказчика, ожидания которого необходимо удовлетворить. Каждый заказчик особенный, те из них, кто покрупнее – взывают несколько громче, информация же все равно прилично исхудает, прежде чем достигнет самой команды. И пока менеджеры продукта играют роль посредников (прокси) по отношению к заказчику, очень сложно отыскать наличные ресурсы для тактического управления продуктом, которые смогли бы управлять тактическими деталями, без которых короткие итерации и быстрая реакция на изменения просто не будут работать.
Коллокация
Большая часть продуктивности гибкой команды исходит из контекста парной работы, ежедневных стендапов, визуального сигнализирования историй и статуса и постоянного неформального общения, являющегося неотъемлемой частью этих методов. Разработчики, владельцы продукта и тестеры не разделены временными зонами или языковым барьером, а сидят вместе. На большом же масштабе коллокация, естественно, не будет практичной даже для больших команд, находящихся в одном офисном здании, то-есть должны быть разработаны иные механизмы.
Архитектура появляется сама
Гибкие методы разработки, в частности XP, приносят разработку дальновидной архитектуры (естественно, требующей дополнительных инвестиций) в жертву возможности быстро рефакторить систему. Исключается, таким образом, некое архитектурное русло, координирующее усилия распределенных команд. Но в случае широкомасштабной системы кривая стоимости рефакторинга, которую мы обсуждали в Части 3, может быть далекой от реальности, так как для разработки хотя бы первого релиза может понадобиться, скажем, сотня человеко-лет. И поскольку agile в целом не учит, как подходить к разработке архитектуры больших систем, это явное ограничение является настоящим препятствием в принятии гибких методологий.
Недостаточный объем требований и задокументированной спецификации
Практика работы с небольшим количеством пользовательских историй за раз в гибкой разработке является прекрасным механизмом эффективной фокусировки команды. Но что приводит к возникновению этих историй на более масштабных системах? Удовлетворят ли они теперь, собранные вместе (а их теперь – тысячи), потребность пользователя в определенной функции системы от и до? Обладает ли владелец продукта, принадлежащий к определенной команде, видением того, чем занимаются другие команды? Повлияют ли они на нас? Если так, то когда? И коль скоро закончена разрабатываемая система (большое число продуктов, которые разворачиваются совместно и поддерживают определенные функции системы от и до), откуда мы знаем, что пользовательские истории, приклеенные к стенке, действительно работают вместе и выполняют финальное предназначение? Может ли разработка приложения уровня предприятия работать в режиме одной пользовательской истории за раз? Наверное, не совсем.
Культура и физическая среда
Эффективная гибкая среда звучит и выглядит по-иному. Большинство членов команды работает в открытом или близком к открытому пространстве и часто их менеджеры, покинув свои офисы, воссоединяются с командой. Такой процесс может показаться недостаточно эффективным, так как повешенные на стену истории содержат определенную неформальность, доски и фломастеры переносятся то туда то сюда и люди в команде, кажется, больше разглагольствуют, нежели пишут код.
Для некоторых людей такой сценарий может показаться неконтролируемым, хаотическим и даже непрофессиональным, потому что такая команда может не отражать атрибутов, которые мы предполагаем видеть в эффективной, хорошо организованной компании. Мы также заметили, что почему-то у гибкой команды стиль одежды всегда менее строгий по сравнению со стандартным и комбинация свободного стиля, работы в парах, постоянного общения и персонала, застрявшего в обсуждении у доски не очень хорошо воспринимается в некоторых корпоративных кругах.
Ограничения компании
В сочетании с вышеописанными ограничениями, компания также тащит свой собственный багаж в “в таблицу прогресса гибкой разработки”. Естественно, компания – это живой организм, и как любой живой организм она давно впитала в себя знания как себя защитить – и меры самозащиты порой достигают чудовищного эффекта и силы. Рассмотрим типичные препятствия.
Организации управлений процессами и проектами
По мере своего роста компании учреждают инфраструктуру для контроля и оценки проектов и программ. Подобные организации часто являются движущей силой для формализованных подходов и процедур разработки. Многие организации, ведомые настоящими бизнес-потребностями, стремятся измерить такие величины как “капитализация” (издержки на разработку по времени в таблице баланса компании), “переходы через бизнесс-этапы (stage gates)” (метрики, определяющие, когда проект формализован и для компании имеет смысл его поддерживать, движется ли проект в правильном русле и т.д.).
Вдобавок, внешние аудиты, производимые официальными службами, заказчики (например, фармацевтические компании) также могут интересоваться такими типичными средствами “контроля” за процессом разработки, как “завершение и официальная передача в разработку спецификации требований”, “завершение тест-плана и одобрение его отделом по контролю за качеством” и т.д. И, собственно, гибкие команды подобных артефактов не используют и, как следствие, не разрабатывают, если только это не требуется специально. Поскольку организации управлений проектами и члены их команд играют ключевую роль в поддержке текущих и будущих процессов, они могут прилично сопротивляться всяким изменениям, в частности, изменениям, влекущим за собой упразднение средств контроля и документов, от которых жизненно зависит успех их работы.
К счастью, во многих компаниях эти организации могут, напротив, быть движителем изменений и многие из этих организаций поддерживали инициативы по внедрению гибкой разработки как механизма усовершенствования эффективности компании. Эти организации могут стать или не стать союзниками, но и в том и в другом случае они представляют собой огромную силу.
Существующие формализованные политики и процедуры
Весьма вероятно, у таких команд остались шрамы от прошлых проектов, к которым они впоследствии пристроили средства контроля. Также в прошлом они обращались к командам разработчиков и установили некоторые процессы с формальными фазами, водопад, например, которые и мы продвигали в прошлом, находясь на совсем другом уровне производственной зрелости. Весьма привычно видеть такие контрольные точки завершения фазы как “дизайн системы завершен” или “ревью дизайна утверждено” в опубликованном руководстве по разработке продукта. И эти формализованные, опубликованные и принятые руководства не так уж просто изменить. Но все же, большинство из этих политик и процедур должно быть исправлено, изменено или устранено, чтобы способствовать гибкой разработке. Эти задокументированные политики не могут быть просто проигнорированы, – они могут породить настоящие препятствия в принятии agile.
Корпоративная культура
Компании со временем возделывают устойчивую культуру, определенные моменты в которой могут не быть выгодными для agile. Например, как мы уже ранее заметили, один вид среды гибкой разработки может показаться несоответствующим. Вдобавок, если преданность компании измеряется количеством отработанных часов, а не эффективностью, гибкая команда не будет чувствовать себя достаточно мотивированной, адекватно оцененной и вознагражденной. Поскольку agile интенсивен в тактическом плане, а также в силу ежедневной и еженедельной сфокусированности и фактической отчетности, 40-часовая рабочая неделя оказывается единственным выходом, так как именно там лежит максимальная продуктивность. (Принцип из Манифеста гибкой разработки: “Гибкие процессы способствуют устойчивой разработке”) Если требуется сверх этого – гибкая разработка не будет верным выбором.
Система компенсации может быть также плохо продумана. Система, отдающая предпочтение индивидуальному вознаграждению над командным может помешать парной работе, групповым обсуждениям и т.д. столь необходимым для завершения итерации. Да, каждый отвечает за свою работу, но каждый также несет ответственность и за команду, поэтому система вознаграждения должна пройти определенную эволюцию, чтобы фактически ощутить это различие.
Строгая командно-административная культура также может заморозить agile. Если менеджмент диктует букву закона по всевозможным процессам и технологиям, команды не смогут развиться до уровня самоорганизации равно как не получат возможности постоянно качественно изменяться, что, собственно, характеризует гибкую разработку. Также они не смогут избрать оптимальное техническое русло на пути к желаемому решению если решение будет диктоваться другими.
Фиксированный график, фиксированная функциональность
Если к команде снисходит поручение доставить функциональность X за период времени Y имея в распоряжении ресурсы Z, то это уже по определению не удовлетворяет сакральным правилам agile, состоящим в фиксированном времени, но нефиксированном объеме функциональности. И потому гибкие команды окажутся обескураженными уже в самом начале проекта . Этот способ управления является все-таки обычным в индустрии, и его еще придется в будущем преодолеть. Действительно, командам присуще желание иметь способность в точности предсказывать, когда и какую функциональность они смогут доставить, но они осознают, что это просто невозможно и для них представляется откровенно глупым, когда менеджмент просто требует: “Сделайте, чтоб было именно так”.
Трения между командой разработчиков и прокси заказчика
Также часто случается, что команды, разрабатывающие продукт и их сотрудники в отделах маркетинга, операционных отделах и т.д. давно уже натерли друг о друга болезненные мозоли. Соответственно, многим сотрудникам извне команды разработчиков кажется, что команда просто “опять сорвала доставку”. Получаем недоверие в качестве следствия.
Для команды же разработчиков кажется очевидным, что их внешние стейкхолдеры “просто не понимают, что это исследование и разработка, а не просто разработка”. Нельзя определенно сказать кто из них прав, а кто нет, но однозначно в agile им придется работать в непосредственной близости. (Принцип из Манифеста гибкой разработки: “Люди бизнеса и разработчики должны совместно работать каждый день на протяжении всего проекта”.) Им необходимо научиться доверять навыкам и посильному вкладу друг друга. Установить такой уровень доверия – задача не простая, но результат себя окупает и служит сильным стимулом для всех вовлеченных сторон.
Сотрудники организованы по дисциплинам, а не по продуктам
Понятие организация само по себе является корнем всех препятствий по отношению к гибкой разработке, так как организация уже каким-то образом организована и организована, скорее всего, по функциям (управление продуктом, архитектура, разработка и т.д.) нежели по линии продуктов или приложений. В agile разработке команды быстро реорганизовываются, дабы удостовериться в полном наборе ресурсов, необходимых для определения/разработки/тестирования и доставки компоненты или определенной функции системы. Это требует выделенных (но не в избытке, конечно) ресурсов на проект, иначе команда провалит обязательства по итерации. Реорганизация обычно требует переопределения того, что делает команду командой в этой компании.
Компании являются компаниями, потому что выросли вместе со своим успехом. Для большинства компаний успех очень часто связан с приобретением команд или линеек продуктов или существующих ИТ-компаний по мере своего развития. Эти команды редко расположены поблизости и, чем больше организация, тем менее вероятно, что они окажутся вместе.
Более того, сам по себе штат сотрудников не может быть коллоцирован, потому что физически это сделать не получится с даже сотней человек в одном рабочем пространстве. Таким образом, проблема распределенной команды естественно свойственна agile на большом масштабе.
ИтогиМы определили массу вопросов в этой части книги: те вещи, которые могут помешать принятию гибкой разработки в масштабе компании. Мы делаем это с твердой уверенностью, что людям трудно принять методы решения проблем, которых, по их мнению, у них нет. Но на самом деле большинство компаний, даже небольших, удостоверятся, что часть или все из вышеописанных проблем им присущи. И сознание этого – первый шаг к их решению. В последующих частях книги мы разрешим эти задачи по мере движения к созданию гибкой компании.
