Первоначально я собирался написать статью о том, как правильно и эффективно организовать процесс разработки с использование Agile-методологий. Однако, посидев некоторое время над пустым окном редактора, я понял, что сам не знаю, как это сделать. И не потому, что это невозможно. Каждый проект уникален и нельзя создать общий рецепт, который будет работать везде и всегда. В тоже время, в процессе обдумывания статьи, мне вспомнилось несколько типичных ошибок внедрения гибких технологий, которые если и не уничтожат, то гарантированно подпортят результат. Поэтому, действуя согласно принципу от обратного, я решил написать про них.
Прежде чем начать, стоит напомнить о том, что такое Agile. В чистом виде Agile это методология разработки, базирующееся на принципах Agile Manifesto. Вкратце, основанная суть этих принципов заключается в нацеленности на результат за счет эффективной коммуникации, отсутствия лишнего, высокой гибкости и постоянной готовности к изменениям (Более подробно можно почитать в Википедии). Сама по себе Agile в чистом виде не реализуется, для этого используются такие практические методологии, как XP, Scrum, Lean и прочие, которые строятся на базе Agile принципов и объясняют, как их реализовать. В данной статье будет рассматриваться именно Agile в целом, без уклона в конкретную реализацию.
Ну а теперь, собственно, можно перейти рассмотрению способов «убийства» Agile.
Предположим, что некий руководитель прочитал много литературы по Agile и сейчас горит желанием применить эти знания на практике. Его бодрая речь может выглядеть примерно так:
С сегодняшнего дня мы начинаем работать 100% по Agile. У нас будут ежедневное, оценочное, промежуточное, итоговое, ретроспективное, еженедельное и ежемесячные обязательные совещания. Каждая задача должна находиться в одном из 46-ти утвержденных статусов, которые учитывают все возможные варианты, в том числе и нахождение разработчика на перекуре, на обеде или в туалете – не забывайте, кстати, менять ей статус, когда соберетесь в одно из этих мест. Кроме того, я прочитал, что одни ребята каждый день возносили молитву Алану Тьюрингу и у них было все хорошо – поэтому мы тоже так будем делать.
Но не все так просто. Каждая Agile-методика имеет свою определенную область применения и совершенно не факт, что она будет востребована в конкретной команде на конкретном проекте. Принимая новую методику важно видеть ее не формальную, а практическую сторону: в чем ее назначение, как она работает и какие несет эффекты. Кроме того, не следует забывать о постоянном анализе: работает ли еще она, не требует ли каких-либо изменений, как можно усилить ее положительные и убрать негативные эффекты?
А вот такие мысли бывают у людей решивших работать по Agile. В начале:
Ну, все, у нас есть Agile и теперь-то мы заживем!
Через месяц:
Надо еще подождать, сейчас-то уж точно все пойдет.
Через два месяца:
К черту этот Agile! Попробовали – ничего не работает! Это все консультанты придумали, чтобы деньги грести.
Любую методологию реализуют люди. Не стоит ждать, что Agile заработает, только потому, что вы решили ее использовать. Даже поддержка Agile требует определенных трудозатрат, не говоря уж про внедрение. От каждого члена команды, и в особенности от руководителей, необходимо активное участие в подготовке и организации процессов разработки. Кроме того, Agile не предусматривает конечного пункта развития – процесс самоанализа и совершенствования может идти бесконечно.
Типичная ситуация. Есть у нас крутой и опытный программист Петя. Ему некогда играться в эти новомодные штучки – он пишет суровый код. И общаться с коллегами он тоже не очень любит – все равно они не поймут всю гениальность его сурового кода. Поэтому Петю не трогают, пусть и дальше сам по себе работает, тем более, он приходит на работу по ночам и его редко когда видят. Петя – программист опытный, сам знает, что и как надо правильно делать.
Однако Agile игра командная. И когда один игрок играет не по правилам, это сказывается на результате всей команды. В итоге, кажущаяся высокая индивидуальность эффективность программиста-одиночки может быть полностью нивелирована негативным эффектом, оказываемым им на всю команду.
Иногда от руководителей можно услышать нечто наподобие такого:
Так, ребята, заказчик от нас сейчас требует срочный релиз, поэтому бросаем все методологии и начинаем усиленно кодить. Ну а потом, как поспокойней станет, опять продолжим.
А спокойней потом не становится. Сначала приходится срочно чинить то, что было поломано спешным релизом, потом то, что было поломано спешной починкой, потом идет починка починки и т.д.
Неверно думать, что Agile это методология для спокойного периода разработки, когда есть много времени на всякие необязательные активности (хотя внедрять ее, конечно, лучше именно в такой период). Как раз таки наоборот — основное назначение Agile сделать разработку контролируемой и эффективной в любой момент времени, что особенно актуально в сложные периоды. И отказавшись от гибких методологий в конце разработки можно запросто уничтожить весь полученные от них эффект ранее.
Когда-то я услышал про такую вещь как парное программирование, а через некоторое время мне выдалась возможность попробовать это на практике. После нескольких дней работы в паре я был откровенно разочарован. Работа шла медленно, мы с напарником постоянно спорили по мелочам, вплоть до того как форматировать код, и в итоге принимали компромиссные решения, которые никому из нас двоих не нравились. От работы в паре оставался неприятный осадок и в один из дней по обоюдному молчаливому решению мы вернулись к работе по одному. Через некоторое время мы опять попробовали поработать в паре, потом снова вернулись к самостоятельной работе, а потом опять к парному программированию… И вдруг, в какой-то момент, я понял, что мне нравится работать в паре гораздо больше чем в одиночку! Мы с напарником смогли подстроиться друг к другу, поняли и приняли определенные правила поведения в паре, в конце концов, просто привыкли к чужому стилю программирования. В итоге работа стала гораздо более эффективной, а результаты, полученные в паре, приносили больше удовольствия, чем индивидуальные достижения.
Практически любая новая методология не начинает работать сразу на полную мощь. Скорее даже наоборот – обычно всегда есть некоторый период привыкания и обкатывания, когда эффективность работы снижается (порой значительно!) по сравнению с предыдущими методами. И лишь те, кто смогли преодолеть этот период, не испугались и не остановились на середине пути, получат в конце концов желаемый эффект.
Что ж, вроде все наладилось, процесс выверен до мелочей, релизы стабильно идут, заказчик счастлив. Кажется, найдена идеальная рабочая формула Agile? Теперь ее всегда можно будет применять!
Потом приходят новые люди в команду, меняются цели и задачи проекта… сменяется фаза луны, наконец. И идеальная формула перестает работать и даже начинает мешать. К сожалению, не существует единого идеального рецепта Agile. Каждый из них может быть хорош только в какой-то одной конкретной обстановке и вреден во всех остальных. Более того, готовность к изменениям и постоянное самосовершенствование являются одними из основных принципов Agile. Может это даже и хорошо – предсказуемый и линейный мир был бы достаточно скучен.
Безусловно, здесь описаны далеко не все возможные способы, а лишь те, которые я встречал и которые показались мне типичными. Думаю, существуют еще множество вариантов как не реализовать Agile или значительно уменьшить эффективность. Если вы знаете еще типичные или интересные способы, напишите, пожалуйста, про них в комментариях.
Что такое Agile
Прежде чем начать, стоит напомнить о том, что такое Agile. В чистом виде Agile это методология разработки, базирующееся на принципах Agile Manifesto. Вкратце, основанная суть этих принципов заключается в нацеленности на результат за счет эффективной коммуникации, отсутствия лишнего, высокой гибкости и постоянной готовности к изменениям (Более подробно можно почитать в Википедии). Сама по себе Agile в чистом виде не реализуется, для этого используются такие практические методологии, как XP, Scrum, Lean и прочие, которые строятся на базе Agile принципов и объясняют, как их реализовать. В данной статье будет рассматриваться именно Agile в целом, без уклона в конкретную реализацию.
Ну а теперь, собственно, можно перейти рассмотрению способов «убийства» Agile.
Превратить в формальность
Предположим, что некий руководитель прочитал много литературы по Agile и сейчас горит желанием применить эти знания на практике. Его бодрая речь может выглядеть примерно так:
С сегодняшнего дня мы начинаем работать 100% по Agile. У нас будут ежедневное, оценочное, промежуточное, итоговое, ретроспективное, еженедельное и ежемесячные обязательные совещания. Каждая задача должна находиться в одном из 46-ти утвержденных статусов, которые учитывают все возможные варианты, в том числе и нахождение разработчика на перекуре, на обеде или в туалете – не забывайте, кстати, менять ей статус, когда соберетесь в одно из этих мест. Кроме того, я прочитал, что одни ребята каждый день возносили молитву Алану Тьюрингу и у них было все хорошо – поэтому мы тоже так будем делать.
Но не все так просто. Каждая Agile-методика имеет свою определенную область применения и совершенно не факт, что она будет востребована в конкретной команде на конкретном проекте. Принимая новую методику важно видеть ее не формальную, а практическую сторону: в чем ее назначение, как она работает и какие несет эффекты. Кроме того, не следует забывать о постоянном анализе: работает ли еще она, не требует ли каких-либо изменений, как можно усилить ее положительные и убрать негативные эффекты?
Надеяться, что все само пойдет
А вот такие мысли бывают у людей решивших работать по Agile. В начале:
Ну, все, у нас есть Agile и теперь-то мы заживем!
Через месяц:
Надо еще подождать, сейчас-то уж точно все пойдет.
Через два месяца:
К черту этот Agile! Попробовали – ничего не работает! Это все консультанты придумали, чтобы деньги грести.
Любую методологию реализуют люди. Не стоит ждать, что Agile заработает, только потому, что вы решили ее использовать. Даже поддержка Agile требует определенных трудозатрат, не говоря уж про внедрение. От каждого члена команды, и в особенности от руководителей, необходимо активное участие в подготовке и организации процессов разработки. Кроме того, Agile не предусматривает конечного пункта развития – процесс самоанализа и совершенствования может идти бесконечно.
Неполная вовлеченность команды в процесс
Типичная ситуация. Есть у нас крутой и опытный программист Петя. Ему некогда играться в эти новомодные штучки – он пишет суровый код. И общаться с коллегами он тоже не очень любит – все равно они не поймут всю гениальность его сурового кода. Поэтому Петю не трогают, пусть и дальше сам по себе работает, тем более, он приходит на работу по ночам и его редко когда видят. Петя – программист опытный, сам знает, что и как надо правильно делать.
Однако Agile игра командная. И когда один игрок играет не по правилам, это сказывается на результате всей команды. В итоге, кажущаяся высокая индивидуальность эффективность программиста-одиночки может быть полностью нивелирована негативным эффектом, оказываемым им на всю команду.
Выборочное применение
Иногда от руководителей можно услышать нечто наподобие такого:
Так, ребята, заказчик от нас сейчас требует срочный релиз, поэтому бросаем все методологии и начинаем усиленно кодить. Ну а потом, как поспокойней станет, опять продолжим.
А спокойней потом не становится. Сначала приходится срочно чинить то, что было поломано спешным релизом, потом то, что было поломано спешной починкой, потом идет починка починки и т.д.
Неверно думать, что Agile это методология для спокойного периода разработки, когда есть много времени на всякие необязательные активности (хотя внедрять ее, конечно, лучше именно в такой период). Как раз таки наоборот — основное назначение Agile сделать разработку контролируемой и эффективной в любой момент времени, что особенно актуально в сложные периоды. И отказавшись от гибких методологий в конце разработки можно запросто уничтожить весь полученные от них эффект ранее.
Ожидать моментальных результатов
Когда-то я услышал про такую вещь как парное программирование, а через некоторое время мне выдалась возможность попробовать это на практике. После нескольких дней работы в паре я был откровенно разочарован. Работа шла медленно, мы с напарником постоянно спорили по мелочам, вплоть до того как форматировать код, и в итоге принимали компромиссные решения, которые никому из нас двоих не нравились. От работы в паре оставался неприятный осадок и в один из дней по обоюдному молчаливому решению мы вернулись к работе по одному. Через некоторое время мы опять попробовали поработать в паре, потом снова вернулись к самостоятельной работе, а потом опять к парному программированию… И вдруг, в какой-то момент, я понял, что мне нравится работать в паре гораздо больше чем в одиночку! Мы с напарником смогли подстроиться друг к другу, поняли и приняли определенные правила поведения в паре, в конце концов, просто привыкли к чужому стилю программирования. В итоге работа стала гораздо более эффективной, а результаты, полученные в паре, приносили больше удовольствия, чем индивидуальные достижения.
Практически любая новая методология не начинает работать сразу на полную мощь. Скорее даже наоборот – обычно всегда есть некоторый период привыкания и обкатывания, когда эффективность работы снижается (порой значительно!) по сравнению с предыдущими методами. И лишь те, кто смогли преодолеть этот период, не испугались и не остановились на середине пути, получат в конце концов желаемый эффект.
Не меняться
Что ж, вроде все наладилось, процесс выверен до мелочей, релизы стабильно идут, заказчик счастлив. Кажется, найдена идеальная рабочая формула Agile? Теперь ее всегда можно будет применять!
Потом приходят новые люди в команду, меняются цели и задачи проекта… сменяется фаза луны, наконец. И идеальная формула перестает работать и даже начинает мешать. К сожалению, не существует единого идеального рецепта Agile. Каждый из них может быть хорош только в какой-то одной конкретной обстановке и вреден во всех остальных. Более того, готовность к изменениям и постоянное самосовершенствование являются одними из основных принципов Agile. Может это даже и хорошо – предсказуемый и линейный мир был бы достаточно скучен.
Заключение
Безусловно, здесь описаны далеко не все возможные способы, а лишь те, которые я встречал и которые показались мне типичными. Думаю, существуют еще множество вариантов как не реализовать Agile или значительно уменьшить эффективность. Если вы знаете еще типичные или интересные способы, напишите, пожалуйста, про них в комментариях.