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

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). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

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

Автор: Илья Павличенко.


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

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

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn)
Перевод с английского


Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Об agile по-русски: User Stories, часть 1

«Разработка ПО - это игра изобретательности и кооперации»
Элистер Коуберн (1)
О чем эта статья? Это одна из статей серии «Про agile по-русски» (см. сноску внизу про значение термина «agile»), идея которых поделиться опытом использования agile принципов (2) в разработке программного обеспечения. Основная суть этих подходов – кооперация между всеми членами проекта и адаптивность процесса разработки к неизбежным изменениям. Также важным аспектом Agile является принятие человеческого фактора в проекте как неотъемлемой части и более того – как наиважнейшей причиной прогресса. Agile акцентирует важность поддержания человеческих отношений и учета человеческих особенностей для успеха проекта.Эта статья рассказывает о применении «userstories» («пользовательских историй») - одной из практик agile. Далее для краткости я буду называть их просто «историями». Для кого эта статья? Эта статья для профессионалов по разработке программного обеспечения: менеджеров продуктов, менеджеров верхнего и среднег…

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn)
Переведено с английского проектом Agile Translations.



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

На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что мы дол…