Юрген Аппело
Agile-менеджмент. Лидерство и управление командами
Моя теория всего
Существует ли теория, которая может помочь менеджерам работать в гибкой среде? За последние несколько десятилетий было предложено много управленческих теорий – впрочем, большинство из них вовсе не будут теориями в строгом научном смысле [Lewin, Regine 2001: 5]. Настоящая научная теория должна быть в состоянии не только указывать на существование каких-либо природных явлений, но и делать проверяемые утверждения о наблюдаемом реальном мире, предсказывая, каких событий следует ожидать, прежде чем их можно будет наблюдать. Именно в этом смысле различные управленческие «теории» не соответствуют ожиданиям. Они зачастую представляют собой не столько теории, сколько наборы технических приемов. Вместо того чтобы давать описание того, как функционирует реальный мир, они предлагают советы (часто полезные), как подойти к той или иной проблеме или ситуации. В этом смысле хорошим примером будет теория ограничений. Это не научная теория, а управленческая философия, которая предлагает способы оптимизации процессов и позволяет добиваться целей, постоянно фокусируясь на имеющихся ограничениях.
Значит ли это, что я в состоянии предложить свою собственную «теорию» гибкого менеджмента, втайне надеясь войти в пантеон таких мыслителей, как Портер, Деминг и Друкер? Боюсь, что нет.
Было время, когда я надеялся изобрести теорию всего, что касалось бы управления разработкой программного обеспечения. Эта теория описывала бы универсальные принципы функционирования любых команд, работающих над созданием программных продуктов, и предоставила бы в помощь менеджерам единую и законченную модель управления такими командами. Оглядываясь назад, я думаю, что в то время мое мышление было жертвой дырявой абстракции.
К счастью, я вскоре понял, что эта цель недостижима по двум причинам. Во-первых, уже существует множество теорий, претендующих на объяснение того, как люди работают в командах (здесь можно порекомендовать книгу «Малые группы как сложные системы» (Small Groops as Complex Sistems) [Arrow 2000], а также журнал «Эмерджентность. Теория сложности в применении к организациям»[2]). Эта область известна как социальная сложность. Во-вторых, сама теория сложности говорит нам, что любые попытки создать единую модель, описывающую сложные системы, неизбежно обречены на неудачу. Эта тема затронута в главе 16 «Все модели неверны, но некоторые из них полезны». Я испытал облегчение, когда понял это: «Сделать это невозможно. Прекрасно! Значит, я могу начать работать над чем-то другим!» Это отличный пример того, когда понимаешь свои заблуждения еще на раннем этапе. (Из теорем Гёделя о неполноте следует, что такая невозможность распространяется и на любые единые теории. Все-таки хорошо, что ученые в своих поисках не сдаются так легко, как я.)
Модель, предлагаемая в этой книге
Эта книга поможет вам стать более хорошим менеджером. В частности, в ней показано, в чем должны заключаться ваши обязанности в качестве Agile-руководителя в компании, занимающейся разработкой программных продуктов на основе гибких методологий. Книга дает богатый инструментарий, что позволяет применять теорию в ежедневной практике. Она объясняет, как нужно управлять командами, исходя из представления, что системы в большинстве случаев оказываются сложными, а не линейными, а также как фокусироваться на адаптивности, а не на предсказуемости. Не имеет особого значения, кто вы – менеджер проекта по разработке ПО, лидер команды, технический директор или программист. В конечном итоге все мы пытаемся управлять окружающей нас средой. Давайте научимся делать это хорошо.
Применяемая в книге модель показана на рис. 1.4. Я называю ее моделью Менеджмента 3.0. Она рассматривает организацию с шести углов зрения. Каждый из этих компонентов описан в книге отдельно, и каждому посвящено по две главы – теоретической и практической. Но прежде чем мы начнем обсуждать модель в деталях, я считаю важным еще раз вернуться к двум базовым комплексам идей, лежащим в ее основе, а именно к гибкости и сложности, а также уделить немного времени истории каждого из этих комплексов. Глава 2 содержит краткий обзор гибких методологий разработки программного обеспечения, а в главе 3 рассматриваются основы теории сложности. Суть модели, то есть способы управления командами разработчиков, вы найдете в центральной части книги, которая открывается главой 4 «Информационно-инновационная система» и заканчивается главой 15 «Улучшение всего». И наконец, глава 16 содержит краткое заключение.
Хотелось бы мне, чтобы подобная книга попала мне в руки десять лет назад, когда я занимался своим стартапом. Но в этом случае вполне могло случиться, что я все же заработал бы свои миллионы и, по всей вероятности, вряд ли стал бы заморачиваться написанием этой книги. По-видимому, все это означает, что планирование карьеры зачастую бывает совершенно бесполезно, а неудачный проект может обернуться удачей – надо только суметь вовремя это увидеть.
Резюме
Человеческий мозг устроен таким образом, чтобы за каждым событием видеть определенную причину. Такое стремление к определению причинно-следственных связей полезно при прогнозировании и планировании. Однако очень часто ситуации куда сложнее, чем может показаться на первый взгляд. Теория сложности говорит нам, что применение линейного мышления для решения сложных проблем чревато болезненными ошибками.
Несмотря на то, что редукционизм (понимание природы системы через осмысление ее составных частей) оказался успешным в науке, в настоящее время общепризнанно, что, следуя по этому пути, можно зайти слишком далеко.
Чтобы разобраться во многих сложных проблемах, необходим более целостный подход, применяемый при изучении сложных социальных систем. Такой подход предлагает целостное представление о взаимодействиях, происходящих в группах людей.
Менеджмент 3.0 – это модель для Agile-менеджмента, которая позволяет применять подходы теории сложности к управлению командами, занимающимися разработкой программных продуктов с использованием гибких методологий.
Подумать и сделать
Давайте посмотрим, как применить некоторые идеи данной главы в вашей компании:
• Возьмите в качестве примера какую-нибудь реальную нерешенную проблему из своей профессиональной сферы. Попробуйте представить, в чем может состоять ее причина. Уверены ли вы, что эта причина – единственная? Почему вы так считаете? Обсуждали ли вы эту проблему со всеми заинтересованными сторонами? Все ли из них согласны, что проблема вызвана единственной причиной? Проведите такой же анализ для каждой из наиболее важных проблем, с которыми имеете дело. Убедитесь, что вы не упрощаете сложность данных проблем и не пытаетесь устранить причину, которая определена неправильно.
• Если сотрудники вашей компании при анализе проблем пользуются какими-то методиками анализа основной причины (например, методикой пяти «почему»), попробуйте обсудить с ними встроенную в эти методики тенденцию зачастую неоправданно упрощать отношения причины и следствия. У многих явлений, происходящих в сложных системах, имеются множественные причины, а кроме того, причины и следствия могут находиться в отношениях циклической зависимости. В таких ситуациях ни одна из причин не будет главной, поэтому методика анализа основных причин не может в полной мере отражать сложность окружающего мира. Преодолеть упрощенный взгляд на ситуацию можно с помощью дискуссии на эти темы с компетентными коллегами. Организуйте такое обсуждение.
Глава 2
Гибкие методологии разработки ПО
Каждое утро я встаю, преисполненный решимости изменить мир и прекрасно провести время. Иногда это затрудняет составление плана на день.
Э.Б. Уайт, американский писатель (1899–1985)
Для некоторых из вас эта глава необязательна. Если вы знакомы с Agile-методологиями разработки программного обеспечения[3], вы уже и так много знаете (если не все) о том, о чем тут пойдет речь. Эта глава скорее предназначена для тех читателей, которые хотели бы узнать немного больше об истории и основах гибких методологий прежде, чем мы начнем говорить о роли менеджеров в гибких организациях (глава 4 «Информационно-инновационная система»).
В этой книге я исхожу из представления, что вы знаете лишь кое-что об основах гибких методологий. А пока сделайте вид, будто считаете, что XP – это старая операционная система, и продолжайте читать.
Прелюдия к гибким методологиям
Я люблю считать деньги почти так же, как и тратить их. В начале 1990-х годов, когда я учился в Делфтском техническом университете, в свободное время я написал бухгалтерскую программу. Мне было интересно этим заниматься, несмотря на небольшое неудобство: денег, которые нужно было считать, у меня не было. Не исключено, что где-то в глубине души я надеялся, что миллионы появятся автоматически, как только я буду готов их сосчитать. Увы, этого не случилось.
Я был единственным автором этого программного продукта (около 30 000 строк кода). Я не владел формальной методологией, у меня было мало опыта создания ПО, а также не было менеджера, коуча или ментора. Но у меня имелось время, компьютер, видение и страстное желание создать великолепный продукт (рис. 2.1).
К своему удивлению, я сумел продать эту программу дюжине клиентов, и некоторые из них испытали приятный шок от того, что программный продукт может быть простым, удобным для пользователей и иметь симпатичный интерфейс (для программы, написанной в 1990-е годы). Хотя прошло уже двадцать лет, я до сих пор пользуюсь этой программой для управления своими финансами.
Как это вообще возможно? Как неопытному программисту удалось создать продукт столь высокого качества, что он работает почти безупречно вот уже почти двадцать лет?
Не имею ни малейшего представления.
Но… У меня есть список из нескольких пунктов, которые должны быть знакомы последователям гибких методологий разработки.
• Я работал над своим продуктом с энтузиазмом. У меня был кое-какой опыт взаимодействия с бухгалтерскими приложениями, и я был убежден, что их разработали в аду с целью лишить пользователей всех жизненных и душевных сил. Мое видение состояло в том, что мой продукт будет совершенно иным. В отличие от других программ, имевшихся на рынке, пользоваться моим продуктом будет одно удовольствие.
• Я сам был своим критично настроенным заказчиком. Я создавал эту программу для себя, а не для других. Безусловно, я был счастлив, когда мне удалось найти нескольких покупателей, хотя мне и не удалось заработать миллионы, на которые я рассчитывал. Но что бы я ни делал, самым важным было, чтобы продукт работал именно так, как я этого хотел.
• У меня не было плана, только список функциональных возможностей, которыми должен был обладать новый продукт. Я начал с такой наиболее часто применяемой операции, как ввод транзакций. Затем перешел к менее критичным функциям вроде составления баланса и внесения корректировок. В конце добавил такие необязательные приятные вещи, как подсказки и возможность экспорта данных. Я занимался этим до тех пор, пока мне все не надоело, и я просто не объявил продукт готовым.
• Процесс создания программы менялся по мере написания кода. Я начал составлять чек-листы для каждой процедуры, и эти списки постепенно становились все длиннее. Я никогда до этого не слышал о покомпонентном тестировании, но моя система проверок и двойных проверок была не менее надежной, чем та, которой пользуются пилоты.
Вот, собственно, и все. У меня была мотивация, а также критично настроенный заказчик, при этом отсутствовал предварительный план, но присутствовали дисциплина и самоорганизующийся процесс. Не имело никакого значения, что ранее я никогда ничего подобного не делал. Важно было то, что у меня было страстное желание учиться.
Через десять лет после создания своей бухгалтерской программы я узнал, что часть процесса, который я использовал, теперь вдруг стали называть гибкими методологиями разработки ПО. Еще десятью годами позже я начал писать книгу о компонентах, которых, с моей точки зрения, не хватает гибким методологиям. Как не раз бывало раньше, мне казалось, что этот путь позволит заработать миллионы.
Евангелие от Agile
Вначале инженеры сотворили компьютеры и программное обеспечение. Программное обеспечение же было бесформенно и нефункционально, и тьма царила над пользователями. И инженеры сказали: «Да будет структура». И возникла структура.
И даже в избытке.
За последние пять-шесть десятков лет многие инженеры-компьютерщики озаботились проблемой нестабильности качества при разработке ПО. Она объяснялась тем, что разные команды пользовались разными методами разработки, в основном созданными на коленке. И инженеры окунулись в работу. В результате возник ряд формализованных подходов. Родилась профессия разработчика программного обеспечения. Отправной гипотезой служило представление, что создание ПО – чисто инженерная задача. В результате появилось большое количество моделей, методов, подходов и технических приемов, которые, по идее, должны были помочь программистам повысить качество готовых программ. Но странное дело – при реализации большинства проектов эти методы оказывались неэффективными. Гораздо чаще их результатом становилось возникновение очередной бюрократии. Проекты по разработке ПО занимали столько времени и требовали создания такого количества документации, что «формальные» требования к продукту успевали по нескольку раз измениться за то время, что проект находился в разработке. Тем временем небольшим командам программистов удавалось выпускать на рынок продукты гораздо более высокого качества, на порядки дешевле и существенно быстрее. На их стороне были энтузиазм, дисциплина, гибкость и методы, адаптируемые под каждый проект. Эволюция произвела на свет динозавров, но вся пища доставалась муравьям.
В начале 1990-х была предложена новая методология под названием быстрая разработка приложений (Rapid Application Development, RAD). В рамках этой методологии наиболее успешным командам разработчиков удавалось сочетать некоторые формализованные методы, позаимствованные у «тяжеловесного» инженерного подхода (контроль за внесением изменений в техдокументацию, инспекции и применение контрольных показателей), с такими продиктованными практикой методами, как создание прототипов, выпуск инкрементных версий ПО и тесное сотрудничество с заказчиком [McConnell 1996]. В результате такого скрещивания формализованных и неформализованных методик возникли первые «легкие» методологии, включая эволюционное управление разработкой (Evo) (1988), Scrum (1995), методы разработки динамических систем (DSDM) (1995), методы Crystal (1997), Экстремальное программирование (XP) (1999), разработка, управляемая функциональностью (FDD) (1999), прагматическое программирование (1999) и адаптивная разработка ПО (2000).
Как следствие внезапного и почти одновременного появления множества методик, статей, книг и семинаров по «легким» методологиям (некоторые даже сравнивали его с Кембрийским взрывом), у лидеров движения возникла идея собраться и обсудить положение дел. В 2001 году они встретились на лыжном курорте в штате Юта. Там и был выбран термин «гибкие методологии» (Agile), заменивший применявшуюся ранее терминологию, а также был создан Agile-манифест разработки ПО (рис. 2.2).
Agile-манифест многими рассматривался в первую очередь как реакция против бюрократического характера существовавших на тот момент формальных подходов, которые были слишком «упорядоченными». Но лишь немногие поняли, что авторы манифеста также выступают против отсутствия дисциплины у программистов, против «хаотических» процессов и низкого качества, которое в то время доминировало на рынке ПО. Лидеры нового движения осознали, что существует средний путь между структурированностью и отсутствием структуры, между упорядоченностью и хаосом. В определенном смысле это была героическая попытка вернуться к более ранней эпохе, когда основными игроками были программисты-первопроходцы, но анархии при этом не было.
Впоследствии группа наиболее авторитетных представителей Agile-движения создала Agile Alliance[4] – некоммерческую организацию, которая ставит себе целью продвижение гибких методологий во всем мире. Возникла целая новая экосистема, состоящая из конференций, консультантов, книг и журналов. В результате процессы разработки программного обеспечения стали Agile c большой буквы А, превратившись в нечто более глубокое, чем просто набор практик, которые можно использовать при разработке софта. Признавая, что проекты по разработке программного обеспечения существуют в области, которая располагается между упорядоченностью и хаосом, Agile-подходы, по сути, превратились в образ жизни.
Фундаментальные принципы Agile-методологий
В наши дни численность людей, которые разделяют ценности и принципы Agile-методологий, составляет несколько миллионов человек. Опросы подтверждают, что большинство разработчиков программного обеспечения во всем мире придерживаются по крайней мере некоторых из «основных Agile-практик» [VersionOne 2009].
Фундаментальные принципы Agile-методологий были неоднократно описаны, и у многих авторов это получается гораздо лучше, чем у меня. И все же я чувствую необходимость привести в своей книге их краткий обзор. Будучи практиком гибких методологий, я предпочитаю делать все так, как удобно лично мне; поэтому кратко опишу их основные положения, перечислив «семь измерений», в которых «живут» проекты по разработке ПО, – и еще раз вернусь к этой теме в главе 11 «Развитие компетенций».
Люди
Прежде всего Agile-методологии признают за людьми их уникальность и не относятся к ним как к взаимозаменяемым ресурсам. Также признается, что основную ценность представляют взаимодействия и сотрудничество между людьми, а не их индивидуальные компетенции. Данный подход также предполагает работу в небольших кросс-функциональных командах, объединяющих людей, выполняющих разные роли (разработчиков, дизайнеров, тестировщиков и так далее). Предпочтительным вариантом будет размещение команды в одном помещении. От команды требуется самоорганизоваться, что означает отсутствие навязываемых извне методов или рабочих процессов. Команде доверяется выполнение определенной работы, исходя из представления, что ее члены знают, как эту работу выполнить, и осознают свою ответственность за результат.
Функциональность
В рамках Agile-методологий признается, что лучшие программные продукты создаются в условиях, когда заказчик максимально вовлечен в процесс разработки. Команда сотрудничает с заказчиком (или его представителем), поддерживая в актуальном состоянии backlog проекта и постоянно обновляя совместные приоритеты. Описание желаемой функциональности осуществляется в предельно кратком виде и детализируется только непосредственно перед началом работы над ней. Простота будет ключом к хорошему дизайну каждой из функциональных возможностей. Полезность данной функциональности оценивается и подтверждается клиентом сразу же после ее создания.
Качество
Качество играет определяющую роль в успехе продукта, поэтому в центре внимания Agile-методологий находится техническое совершенство. Высокий технический уровень обеспечивается посредством разработки через тестирование (написание протокола тестирования готового продукта предшествует созданию собственно программного кода), ревью кода (часто в сочетании с парным программированием), Definition of Done (чек-лист готовности элементов), итеративной разработки (адаптация кода в результате появившихся изменений или других обстоятельств) и рефакторинга (непрерывная оптимизация кода даже при отсутствии изменений в функциональности). Сторонники гибких методологий признают необходимость последовательного улучшения дизайна; под этим понимается, что в начале проекта архитектура продукта не разрабатывается в деталях (а только в самом базовом виде) и выявляется при дальнейшем развитии проекта.
Инструменты
Сторонники Agile-методологий считают, что инструменты – наименее важный из факторов, влияющих на успешность проекта. И тем не менее инструменты часто упоминаются и продвигаются в литературе по гибким методологиям. Опытные Agile-команды предпочитают инструменты, позволяющие осуществлять ежедневные сборки, непрерывную интеграцию и автоматическое тестирование. Команды нуждаются в мотивации, поэтому повторяющиеся скучные операции должны быть автоматизированы. Многие сторонники гибких методологий в качестве обязательного условия выдвигают наличие поддерживающей «среды обитания» в виде открытого офисного пространства, а также информационные радиаторы (к ним относятся, например, доска задач и диаграммы сгорания задач). Предназначение инструментов в контексте Agile-методологий – усиливать мотивацию, коммуникации и сотрудничество внутри команды.
Время
У Agile-методологий особые отношения со временем. В Agile-проектах даты поставки, бюджеты и крайние сроки могут устанавливаться почти произвольно. Программное обеспечение создается короткими отрезками, часто в рамках тайм-боксов или «спринтов», и поставляется в виде инкрементных релизов; при этом каждый из релизов сам потенциально является готовым к поставке продуктом. Это позволяет владельцам бизнеса управлять графиком проекта, сдвигая дату сдачи готового продукта вперед или назад в зависимости от того, в какие сроки они хотят сделать доступной ту или иную функциональность. Тем временем команда стремится найти для себя оптимальную скорость разработки, которую она сможет поддерживать практически бесконечно.
Ценность
Одной из важнейших причин создания Agile-манифеста было стремление подчеркнуть важность своевременной реакции на изменения. Среда, в которой функционирует программный продукт, никогда не бывает статичной. Функциональность, которая еще вчера представляла собой значительную ценность, завтра может оказаться бесполезной, включая функциональность, которая уже имеется в версиях продукта, переданных заказчику. Разработчики, практикующие гибкие методологии, стараются справиться с этой проблемой, предпочитая короткие циклы разработки и обратной связи. Смысл частых релизов программного продукта не только в том, чтобы получить обратную связь от пользователей и учесть ее в последующем процессе разработки, но и в том, чтобы предоставить пользователям новую функциональность как можно скорее после выявления их потребности в ней, тем самым повышая ценность ПО для клиента.
Процесс
Несмотря на то, что доминирующая парадигма Agile-методологий – люди, а не процессы, это совсем не означает, что последние не важны. Наиболее важными процессами в этом контексте будут минимальное планирование (или планирование методом набегающей волны), ежедневное личное общение (часто это происходит в формате ежедневных стендапов) и мониторинг хода проекта через оценку работающего продукта (по функциональным возможностям, принятым клиентом). Приверженцы гибких методологий также признают необходимость непрерывного улучшения, в ходе которого процессы разработки подвергаются регулярной переоценке и перенастройке посредством анализа и ретроспектив (ретроспективных совещаний).
Конфликт
Все вышеизложенное отражает мое понимание сущности Agile-методологий. Естественно, это не более чем моя точка зрения. Некоторые разработчики, практикующие гибкие методологии, могут не согласиться с приведенным мной кратким описанием. Но это вытекает из самого характера Agile-методологий. Я даже мог бы включить понятие «конфликт» в качестве восьмого измерения, присущего этим методологиям. Как вы увидите позже, наличие внутреннего конфликта – естественное свойство сложных систем и необходимое условие для креативности и инноваций. Великая честь оказаться среди людей, которым ничто не доставляет такого удовольствия, как возможность совершенствовать друг друга.