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

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-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

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

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

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

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

Конференция: Agile Gathering 3

The 3rd Agile Gathering done! First of all, let me thank everyone who came. Seems Agile techniques are becoming more and more popular, we are very happy to play an active part in the Ukrainian Agile movement. Visit our photo album . Below you can find the agenda with the links to the materials where available. What Certified ScrumMaster is NOT - by Alexey Krivitsky, pdf Agile for Business - by Gleb Arshinov, pdf Agile experience of Code Sprinters: How to build a company you would like to work in - by Adam Byrtek, pdf Pragmatic Agile Adoption - by Askhat Urazbaev, pdf We hope that Naresh Jain from Agile India and Danny Kovatch from Agile Israel who were not able to get to Ukraine this time will visit our next gathering in Spring 2008. Watch for upcoming announcements on our web site ( feed available ) and in our discussion group . And let me thank our great sponsors again, without them this event would not have happened: Co-organizer and general partner General and media partner Pa

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

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