К основному контенту

Agile or not Agile: внедрять ли у себя в компании Agile-методологию

Автор: Артём Сердюк
Agile становится сейчас самой популярной методологией разработки программ. Однако всем ли организациям полезно внедрять у себя Agile? Одинаково ли это полезно только что начавшему стартапу из 3-х человек и компании с 20-ти летним опытом на рынке и несколькими тысячами сотрудников? Какие выгоды приносит Agile разным организациям, и какие типичные проблемы могут возникнуть при внедрении? На эти вопросы я постараюсь ответить ниже.

Управленческие функции организации

Ицхак Адизес утверждает, что любая организация, чтобы быть успешной, должна быть эффективной и продуктивной. Эффективность – это способность достигать поставленных целей, а продуктивность – способность делать это с наименьшими затратами. Фирма должна быть эффективной и продуктивной в краткосрочной и долгосрочной перспективе.


Также Адизес утверждает, что для того, чтобы быть успешной, в организации должны присутствовать 4 управленческих функции (http://www.adizes.ru/concepts/roles).


Первая функция (P) – это «Provide needs», «удовлетворение потребностей» - решение насущных задач. Она делает организацию эффективной сейчас.


Вторая (А) – «Administration», это способность снова и снова успешно решать повторяющиеся задачи; другими словами это – налаженные и эффективные процедуры. Она делает организацию продуктивной сейчас.


Третья (E) – «Entrepreneurship», это возможность предугадывать (и предпринимать) действия, которые в будущем позволят компании достигать поставленных целей. Эта функция делает организацию эффективной в долгосрочной перспективе.


Четвертая (I) – «Integration». Это гармонизация частей организации, чтобы они вместе работали для достижения общей цели. Она делает организацию продуктивной и устойчивой в долгосрочной перспективе.




Второе утверждение Адизеса – любая компания проходит в своём развитии определённые этапы. Каждый этап тем, что функций PAEI у организации развиты по-разному. У фирмы на разных этапах развития разные размеры, цели, проблемы, возможности... и количество денег естественно ;).

Подробнее о ролях тут – www.comizdat.com/img/paei12008.pdf

Как влияет Agile на управленческие функции в организации?

Напомню, аджайл-манифест утверждает следующее:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Рассмотрим, как это укладывается в PAEI-модель:

<
I (интеграция)
E (перспектива)
- Individuals and interactions over processes and tools
- Customer collaboration over contract negotiation
?
?
- Working software over comprehensive documentation
- Responding to change over following a plan
A (процессы)
P (продуктивность)


Очевидно, что аджайл-манифест предлагает процесс P--I. Такой процесс будет хорошо работать в постоянно меняющейся среде, в которой каждая следующая задача не похожа на предыдущую.

Кроме того, акцент сделан на интеграцию внутри команды и интеграцию с клиентом, что повышает шансы на выживание команды.


Рассмотрим практики аджайл-процесса (на примере Скрама). Какой процесс предлагает Скрам согласно коду PAEI?

I (интеграция)
E (перспектива)
- Клиент/Product owner постоянно доступен
- Кросс-функциональная команда
- XP-практики (парное программирование, code review, непрерывная интеграция)
- Короткие спринты
- Product backlog
- Планирование спринта
- Демо
- ХР-практики (рефакторинг)
- ScrumMaster
- Ретроспектива
- Impediments backlog
- Доска задач
- Ежедневный скрам
A (процессы)
P (продуктивность)


Исходя из этого, можно сказать, что Скрам предлагает процесс PaEI.


Адизес утверждает, что для того, чтобы перевести организацию на следующий уровень, лидер (или процесс) должен обладать PAEI-кодом следующего уровня.


Давайте посмотрим, каким компаниям подойдёт процесс по Скраму, и какие элементы фреймворка им будут наиболее полезны.

Жизненный цикл организации

Нормальный жизненный цикл организации по Адизесу выглядит так:

  1. Paei – младенчество
  2. PaEi – детство (давай-давай)
  3. pAEi – юность.
  4. PАЕi – расцвет
  5. PАei – закат
  6. pAeI – аристократизм
  7. -А-I – салем-сити
  8. -A-- – бюрократия
  9. ---- – смерть

Более подробно этапы жизненного цикла организации рассмотрены ниже.

Рассмотрим, как подходит Скрам и его отдельные практики организациям разных «возрастов».
<![endif]-->
Этап развития
Код
Что нужно для развития
Подходит ли Скрам
Agile best fits
Использовать осторожно
Младенчество Paei Планирование + деньги (PE) да Product backlog, планирование спринта, короткие итерации Ретроспектива, ScrumMaster
Детство (давай-давай) PaEi Орг структура + команды (AE) да (частично) ScrumMaster
Кросс-функциональная команда
Доска задач
Ежедневный скрам
Ретроспектива, планирование спринта
Юность. pAEi Орг структура + команды (AI) нет Ежедневный Scrum, доска задач, ScrumMaster, ретроспектива
Расцвет PАЕi Стратегические инициативы и корпоративная культура (EI) да Product backlog, планирование спринта, Ретроспектива Короткие итерации
Закат Pаei Результаты + идеи (PE) да Short sprints, backlog, sprint planning, demo Ежедневный Scrum, ретроспектива
Аристократизм pAeI Результаты + идеи (PE) да Short sprints, backlog, sprint planning, demo Ежедневный Scrum, ретроспектива
Салем-сити -А-I Результаты + идеи (PE) да Short sprints, backlog, sprint planning, demo Ежедневный Scrum, ретроспектива
Бюрократия -A-- Ничего (--) нет -- --
Смерть ---- Ничего (--) нет -- --


Если вы решаете, подходит ли вам конкретный аджайл-процесс, вам стоит сделать следующее:
1) определить, на каком этапе жизненного цилка находится ваша команда или компания;
2) решить, даёт ли аджайл-процесс команде/компании то, что ей нужно на этом этапе.


Этапы жизненного цикла компании

Paei – младенчество

Признак: компания только-только образовалась. Идет процесс проверки: были ли правильными идеи основателя?
Цель: выжить!
Проблемы: смерть в младенческом возрасте (Р--- – все что-то лихорадочно делают, но нет времени остановиться и подумать, что же дальше. Т.е. исключительно реактивная организация, которая захлёбывается в потоке проблем). Может наступить или из-за того, что основатель потерял интерес к компании, или потерял контроль над ней. Вторая причина смерти – у компании закончились деньги.
Лечение:
Развивать навыки прогнозирования, анализа и планирования.
Организовать постоянный приток денег.
Поддерживать инициативы основателя, не дать его интересу угаснуть.

Внедрение Agile:
На этом этапе нужен стиль управления PE (Agile формирует стиль РаEI).
Здесь Agile-методика ничего существенного компании не добавит. Все и так очень сплочены желанием выжить, и организации приходится реагировать на изменения внешней среды просто потому, что у компании нету долгосрочных планов. Внедрить Agile-подход тут просто, если вы убедите основателя. Однако если Agile внедрён неудачно, у компании большой риск погибнуть.

PaEi – детство (давай-давай)

Цель: Сбыт, измеряемый долей рынка. Прибыль.
Признак: взрывной рост. Денег стало достаточно, сбыт растет взрывообразно. Компания занимается очень многими видами деятельности. Инициатива исходит преимущественно от основателя. Полномочия неясны, обязанности хаотичны.
Проблемы: Западня основателя (Р-Е- – как "папа" сказал, так и сделаем). Всё в компании держится на основателе. Всё имеет наивысший приоритет – компания хватается за всё сразу.
Лечение:
Развитие навыков командной работы, укрепление интеграции I внутри компании.
Выбор того, что НЕ СЛЕДУЕТ делать (а на чем – таки СОСРЕДОТОЧИТЬ усилия). Навык расстановки приоритетов.
Создание поддерживающей системы контроля.
Начало делегирования полномочий от основателя компании (профессиональным менеджерам).

Внедрение Agile:
На этом этапе нужен стиль управления АE (Agile формирует стиль РаEI).
В такой компании внедрение Agile будет скорее вредно. Компании нужно немножко стабилизироваться, выработать собственные приоритеты, а не прогибаться во все стороны. Здесь стоит внедрять только отдельные элементы Agile, направленные на синхронизацию и интеграцию: daily standup, product backlog и приоретизацию задач из backlog'а. Внедрить Agile будет опять-таки просто, если основатель будет за.

pAEi – юность

Цель: Прибыль
Признак: родилась функциональная оргструктура, управление перешло от основателей к профессиональным менеджерам, начинается выстраивание и отладка процессов
Проблемы: развод (РА-- или Р-Е- – конфликт между профессиональными менеджерами и генераторами идей. В зависимости от того, кто победил – или ранняя бюрократия, или снова "западня основателя"). В организации нарастают противоречия, разгораются внутренние конфликты, люди тратят силы и энергию на борьбу внутри компании. Появляются клики и фракции, народ увольняется.
Лечение:
создание процессов
создание оргструктуры
передача инициативы (Е) от основателя к компании (роли, отделу).
и при этом не задавить инициативу, и не отбить желание у основателя участвовать в делах

Внедрение Agile:
Организации тут нужен стиль управления РА, а потом АЕ. Тут Agile будет более к месту, чем у организаций-"младенцев" и "детей", т.е. сочетает более-менее определённый процесс и передачу инициативы и власти вниз команде. Вы сможете внедрить Agile, если убедите наёмного топ-менеджера, что это добавит порядка и утихомирит смуты. Снизить риск внедрения Agile можно, построив Agile-процесс для какой-то части организации.

PАЕi – расцвет, PАei – закат

Цель: Прибыль и сбыт
Признак: сформулированные и работающие цели и ценности. Работающая оргструктура. Стабильный рост сбыта и прибыльности. Согласованность внутри организации.
Проблемы: главная проблема – как удержаться в этом состоянии, как не застояться (Р-А-). У компании появляется удовлетворение самой собой, перерастающее в самодовольство. Прекращаются инновации и постоянное совершенствование. Уменьшается желание воплощать новые идеи на практике.
Лечение:
взбодрить предпринимательских дух (Е) – организовать приток новых идей
децентрализация – передача инициативы и ответственности вниз

Внедрение Agile:
На этом этапе нужен стиль управления EI, что как раз подходит под Agile. Именно на этом этапе компания получит от Agile наибольшую пользу.

pAeI – аристократизм

Цель: доход на инвестиции
Признак: Снижаются ожидания роста. Подозрения к внедрению нового. Главный принцип – "Не гони волну". Масса процедур и ритуалов (дресс-код и т.п).
Лечение:
долить в компанию предпринимательских дух (Е) – организовать приток новых идей
сделать так, чтобы эти идеи кто-то реализовывал (Р)

Внедрение Agile: предпочтительный стиль управления – РЕ. Здесь Agile очень нужен, чтобы взбодрить инициативу и получить от неё быстрые результаты. Однако сопротивление как сверху, так и снизу, будет существенным – народ не хочет менять сложившийся порядок вещей. Внедрить Agile вы сможете, если убедите команду, что это ей зачем-то нужно.

-А-I – салем-сити

Цель: собственное выживание в компании
Признак: проблемы в бизнесе, котоыре ведут к жестоким разборкам в компании.
Лечение:
дать всю полноту власти в одни руки
долить в компанию предпринимательских дух (Е) – организовать приток новых идей
подробно планировать свою деятельность и строго контролировать выполнение планов

Внедрение Agile: предпочтительный стиль управления на этом этапе – РЕ. Здесь Agile нужен ещё больше, чем аристократическим организациям. Внедрить его можно только волевым решением руководителя. Но даже если вы и сможете его внедрить, кто будет работать в Agile-команде? Похоже, их придётся переманивать от конкурентов.

-A-- – бюрократия

Цель: политическая власть
Признак: компания выполняет минимум полезных функций, штат в основном состоит из администраторов. Компания изолируется от внешней среды и строит системы защиты от клиентов
Лечение:
Смена топ-менеджмента на такой, которое обеспечивает приток новых идей (Е)
Долгое ожидание, когда же организация начнет что-то делать (Р)

Внедрение Agile: Аналогично "салем-сити". Организационное сопротивление будет поистине ужасно, люди отвыкли что-то производить и брать на себя ответственность.

---- – смерть

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

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Основополагающие принципы Agile-манифеста

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

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.