воскресенье, 30 сентября 2018 г.

Девальвация Agile

Agile идет в массы, его пытаются применить во всем, зачастую даже там, где это не применимо. Но будет ли результат называться Agile?  На эту тему спонтанно пообщались с Иваном Селиховкиным. Попробовали выяснить “нужен ли agile в стройке” и плавно перешли к тому “что есть agile”. Получилось, что Иван взял у меня интервью.






Иван: Алексей, а применим ли Agile на стройке?

Алексей: Насколько я общался со своими клиентами (у нас же решение управления проектами). у них Agile уже есть, точнее почти есть. Выполняются все действия и правила кроме Ретроспективы.


Иван: А что это значит "у них agile есть"? Скрам есть? Т.е. вместо ТЗ - бэклог, в который заказчик на свое усмотрение добавляет или убирает "фичи" разного размера и приоритезирует их? Можно пример такой стройки (пусть и без ретроспективы)?

Алексей: Я имею ввиду работу на площадке.

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

Если говорить о примерах применения CCPM (Метод критической цепи), то тут добавляется еще и фокусировка на цели (использование Full Kit - полный набор материалов, инструментов и ресурсов для выполнения работ) и устранение всех препятствий уровня поставки комплектующих.

Иван: Алексей, а почему ты называешь здравый смысл - agile-ом? Вот в классическом проектном управлении кто или что мешает регулярным коммуникация, утренней синхронизации (в больницах она тоже есть - но там же не принято называть управление отделением словом "agile") и так далее? :) Пока все что ты перечислил - это основа любого менеджмента вообще, разве нет?

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

Поэтому
  • XP - дисциплина = если будешь её следовать, то получишь хорошие результаты 
  • Scrum (Метод "Уухнем") - коммуникационный каркас - выстраивает типовой процесс планирования/контроля 
  • Kanban-метод - метод улучшения бизнес-процесса просто за счет метрик и правил. В нём даже про результат ничего нет. Это метод превращения любой деятельности в Производство и оптимизация оного применяя производственные принципы. 
Agile описывает здравый смысл. и просто дает каркас "что делать" на уровне понимания инженеров и тимлидов не вдаваясь в тонкости управления.

К тому же 90% манифеста - XP, а один из основных принципов XP - действовать в соответствии с инстинктами, а не вопреки. То есть, все правила и действия должны быть обоснованы.

Единственной, отличительной чертой реальной гибкости и адаптивности - является ритм Ретроспективы. До главы "План управления улучшениями" свода Знаний (PMBoK) мало кто дочитывает. Некоторые компании проводят "разбор полетов", особенно, если было ЧП. И тогда у них Agile уже есть. Некоторые внедрили СМК и тогда у них по регламенту есть какие-то процедуры улучшения и пересмотра.

Иван: А можешь пояснить фразу "Единственной отличительной чертой реальной гибкости и адаптивности является ритм Ретроспективы."

Т.е. регулярные ретро = agile, не регулярные = не agile?


Алексей: Можно сказать и так.

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

Приведу примеры отличий:
  • В стройке - этап конструирования 1-2 года, в разработке ПО - 1-5 минут (сборка проекта и получение исполняемого файла) 
  • В маркетинге - нет цели вообще, сплошное экспериментирование, то есть регулярная работа в процессе. 
  • В продажах - даже экспериментов нет, если цикл сделки фиксирован. Если это сложные B2B продажи, то они строятся по процессу “планирование и экспериментирование” с уточнением стратегии. Но в любом случае тут нет цели спринта, вокруг которой собирать команду и “Заказчика" 
Поэтому во всех других отраслях это просто "правила хорошего процесса", цикл PDCA и регулярный менеджмент, в котором от Agile остается только фаза “Act” - корректирование процесса.

Вот смотри, покажу на примере. В любой компании есть ДВА потока:

Поток создания ценности, которым все умеют управлять и корректировать (план-фактный анализ и тд), он обеспечивает адаптацию компании под рынок и изменяющиеся условия внешней среды, и

Поток управления - а про него забывают, это бизнес-процессы, у которых тоже есть метрики которые можно корректировать и которым нужно управлять.

Agile явно прописывает правила работы во вторым потоком обеспечивает рост компании и её развитие. Про второй поток вспоминают только когда "Что-то у нас исполнительская дисциплина снизилась" или "Производительность надо повысить", то есть редко и эпизодически.

В этим правилам я отношу:
- ритм Ретроспективы - напрямую влияет на второй поток
- правила работы с Заказчиком - влияет косвенно за счет управления ожиданиями и управление вовлеченностью Заказчика.


Давай, покажу на картинке:




Уж какая есть, это из нашей презентации решения.


Иван: А какие в agile есть метрики, которых нет в проектном управлении? Пример можешь привести?

Алексей: В том то и дело, что они все есть в проектном управлении! Или они выводятся исходя из целей, например: график "настроения команды".

Иван: Я правильно тебя понимаю, что очень многое на свете - есть agile. И лишь немного agile-ом не является? Вот проектное управление в грамотных руках - agile. Управление хирургическим отделением в стационаре (там регулярные ретроспективы каждое утро) - agile. И так далее?

Алексей: Да, именно так!

Компания по определению не может быть "не agile" она просто помрёт тогда. Потому, что нужно адаптироваться, рынок меняется, сезонность влияет, клиент меняется. У кого-то процессы отточены до совершенства управляемого уровня CMMI-4 и улучшаемого CMMI-5, а кто-то действует по наитию на уровне CMMI-1 адаптируясь, когда совсем прижмет (идем к врачу когда зуб уже болит).

Если смотреть в корень, то в американских компаниях были (и сейчас есть) распространены кубиклы, а у нас такого количества перегородок вообще никогда не было, максимум кабинет на отдел, и кубикл на сектор (если повезет). Это разница культуры индивидуализма и культуры сообществ (землячество)

И это важно, поэтому у нас нет ломки "личного пространства", и уже есть высокий уровень командной поддержки, поэтому часто, не нужны утренние планерки.

Иван: Я понял. Спасибо. Но тогда термин agile очень сильно девальвируется.

Алексей: Да! Но его пихают везде. Это хороший бренд, который продается. Однако, знакомясь с компанией я спрашиваю "А вам зачем Agile?" и "Что беспокоит собственника? На что жалуетесь?" - и в первую очередь выстраиваю систему управления отменяя лишние или улучшая нужные правила.

Agile software development - это конкретный способ достижения конкретных результатов в конкретной сфере. А чтобы он заработал, нужно создать экосистему. У этого способа есть ограничения которые находятся выше него (например много-клиентская среда). И где включаются инструменты проектного управления и Теории ограничений (ТОС)..

Если сменить сферу - остается только ритм PDCA и нужно иметь ответы на вопросы "А что будет означать эта практика в этой области?"

На этой ноте нам пришлось прерваться.

Комментариев нет:

Отправить комментарий