Agile идет в массы, его пытаются применить во всем, зачастую даже там, где это не применимо. Но будет ли результат называться Agile? На эту тему спонтанно пообщались с Иваном Селиховкиным. Попробовали выяснить “нужен ли agile в стройке” и плавно перешли к тому “что есть agile”. Получилось, что Иван взял у меня интервью.
Иван: Алексей, а применим ли Agile на стройке?
Алексей: Насколько я общался со своими клиентами (у нас же решение управления проектами). у них Agile уже есть, точнее почти есть. Выполняются все действия и правила кроме Ретроспективы.
Иван: А что это значит "у них agile есть"? Скрам есть? Т.е. вместо ТЗ - бэклог, в который заказчик на свое усмотрение добавляет или убирает "фичи" разного размера и приоритезирует их? Можно пример такой стройки (пусть и без ретроспективы)?
Алексей: Я имею ввиду работу на площадке.
Вот смотри:
- ритм планирования, синхронизации, сверки плана и факта
- регулярные коммуникации
- утренняя синхронизация (прораб раздающий утром наряды бригадам)
- короткое планирование - план на неделю, сверка.
- приоритизация - при ограниченных ресурсах на объекте я сильно сомневаюсь, что есть детальное планирование последовательности работы бригады на площадке. Исключения составляют работы по ремонту железнодорожных путей где план работ расписан поминутно.
Если говорить о примерах применения CCPM (Метод критической цепи), то тут добавляется еще и фокусировка на цели (использование Full Kit - полный набор материалов, инструментов и ресурсов для выполнения работ) и устранение всех препятствий уровня поставки комплектующих.
Иван: Алексей, а почему ты называешь здравый смысл - agile-ом? Вот в классическом проектном управлении кто или что мешает регулярным коммуникация, утренней синхронизации (в больницах она тоже есть - но там же не принято называть управление отделением словом "agile") и так далее? :) Пока все что ты перечислил - это основа любого менеджмента вообще, разве нет?
Алексей: Чтобы применить "любой менеджмент" - нужно его знать. А тимлиды и инженеры до этого не дорастают. Тот же PMBoK дает много инструментов, но не показывает как конкретно применять всё вместе. Agile это просто типовое решение для решения определенных задач. В частности, дать инженерам прививку регулярного менеджмента.
Поэтому
К тому же 90% манифеста - XP, а один из основных принципов XP - действовать в соответствии с инстинктами, а не вопреки. То есть, все правила и действия должны быть обоснованы.
Единственной, отличительной чертой реальной гибкости и адаптивности - является ритм Ретроспективы. До главы "План управления улучшениями" свода Знаний (PMBoK) мало кто дочитывает. Некоторые компании проводят "разбор полетов", особенно, если было ЧП. И тогда у них Agile уже есть. Некоторые внедрили СМК и тогда у них по регламенту есть какие-то процедуры улучшения и пересмотра.
Иван: А можешь пояснить фразу "Единственной отличительной чертой реальной гибкости и адаптивности является ритм Ретроспективы."
Т.е. регулярные ретро = agile, не регулярные = не agile?
Алексей: Можно сказать и так.
По хорошему Agile software development (ASD)- это противостояние контрактных обязательств и адаптивного, уточняющего подхода. Но перекладывая ASD в другие отрасли мы теряем важное: у нас нет высокой неопределенности или нет объединяющей цели .
Приведу примеры отличий:
Вот смотри, покажу на примере. В любой компании есть ДВА потока:
Поток создания ценности, которым все умеют управлять и корректировать (план-фактный анализ и тд), он обеспечивает адаптацию компании под рынок и изменяющиеся условия внешней среды, и
Поток управления - а про него забывают, это бизнес-процессы, у которых тоже есть метрики которые можно корректировать и которым нужно управлять.
Agile явно прописывает правила работы во вторым потоком обеспечивает рост компании и её развитие. Про второй поток вспоминают только когда "Что-то у нас исполнительская дисциплина снизилась" или "Производительность надо повысить", то есть редко и эпизодически.
В этим правилам я отношу:
- ритм Ретроспективы - напрямую влияет на второй поток
- правила работы с Заказчиком - влияет косвенно за счет управления ожиданиями и управление вовлеченностью Заказчика.
Давай, покажу на картинке:
Уж какая есть, это из нашей презентации решения.
Иван: А какие в agile есть метрики, которых нет в проектном управлении? Пример можешь привести?
Алексей: В том то и дело, что они все есть в проектном управлении! Или они выводятся исходя из целей, например: график "настроения команды".
Иван: Я правильно тебя понимаю, что очень многое на свете - есть agile. И лишь немного agile-ом не является? Вот проектное управление в грамотных руках - agile. Управление хирургическим отделением в стационаре (там регулярные ретроспективы каждое утро) - agile. И так далее?
Алексей: Да, именно так!
Компания по определению не может быть "не agile" она просто помрёт тогда. Потому, что нужно адаптироваться, рынок меняется, сезонность влияет, клиент меняется. У кого-то процессы отточены до совершенства управляемого уровня CMMI-4 и улучшаемого CMMI-5, а кто-то действует по наитию на уровне CMMI-1 адаптируясь, когда совсем прижмет (идем к врачу когда зуб уже болит).
Если смотреть в корень, то в американских компаниях были (и сейчас есть) распространены кубиклы, а у нас такого количества перегородок вообще никогда не было, максимум кабинет на отдел, и кубикл на сектор (если повезет). Это разница культуры индивидуализма и культуры сообществ (землячество)
И это важно, поэтому у нас нет ломки "личного пространства", и уже есть высокий уровень командной поддержки, поэтому часто, не нужны утренние планерки.
Иван: Я понял. Спасибо. Но тогда термин agile очень сильно девальвируется.
Алексей: Да! Но его пихают везде. Это хороший бренд, который продается. Однако, знакомясь с компанией я спрашиваю "А вам зачем Agile?" и "Что беспокоит собственника? На что жалуетесь?" - и в первую очередь выстраиваю систему управления отменяя лишние или улучшая нужные правила.
Agile software development - это конкретный способ достижения конкретных результатов в конкретной сфере. А чтобы он заработал, нужно создать экосистему. У этого способа есть ограничения которые находятся выше него (например много-клиентская среда). И где включаются инструменты проектного управления и Теории ограничений (ТОС)..
Если сменить сферу - остается только ритм PDCA и нужно иметь ответы на вопросы "А что будет означать эта практика в этой области?"
На этой ноте нам пришлось прерваться.
Иван: Алексей, а применим ли Agile на стройке?
Алексей: Насколько я общался со своими клиентами (у нас же решение управления проектами). у них Agile уже есть, точнее почти есть. Выполняются все действия и правила кроме Ретроспективы.
Иван: А что это значит "у них agile есть"? Скрам есть? Т.е. вместо ТЗ - бэклог, в который заказчик на свое усмотрение добавляет или убирает "фичи" разного размера и приоритезирует их? Можно пример такой стройки (пусть и без ретроспективы)?
Алексей: Я имею ввиду работу на площадке.
Вот смотри:
- ритм планирования, синхронизации, сверки плана и факта
- регулярные коммуникации
- утренняя синхронизация (прораб раздающий утром наряды бригадам)
- короткое планирование - план на неделю, сверка.
- приоритизация - при ограниченных ресурсах на объекте я сильно сомневаюсь, что есть детальное планирование последовательности работы бригады на площадке. Исключения составляют работы по ремонту железнодорожных путей где план работ расписан поминутно.
Если говорить о примерах применения CCPM (Метод критической цепи), то тут добавляется еще и фокусировка на цели (использование Full Kit - полный набор материалов, инструментов и ресурсов для выполнения работ) и устранение всех препятствий уровня поставки комплектующих.
Иван: Алексей, а почему ты называешь здравый смысл - agile-ом? Вот в классическом проектном управлении кто или что мешает регулярным коммуникация, утренней синхронизации (в больницах она тоже есть - но там же не принято называть управление отделением словом "agile") и так далее? :) Пока все что ты перечислил - это основа любого менеджмента вообще, разве нет?
Алексей: Чтобы применить "любой менеджмент" - нужно его знать. А тимлиды и инженеры до этого не дорастают. Тот же PMBoK дает много инструментов, но не показывает как конкретно применять всё вместе. Agile это просто типовое решение для решения определенных задач. В частности, дать инженерам прививку регулярного менеджмента.
Поэтому
- XP - дисциплина = если будешь её следовать, то получишь хорошие результаты
- Scrum (Метод "Уухнем") - коммуникационный каркас - выстраивает типовой процесс планирования/контроля
- Kanban-метод - метод улучшения бизнес-процесса просто за счет метрик и правил. В нём даже про результат ничего нет. Это метод превращения любой деятельности в Производство и оптимизация оного применяя производственные принципы.
К тому же 90% манифеста - XP, а один из основных принципов XP - действовать в соответствии с инстинктами, а не вопреки. То есть, все правила и действия должны быть обоснованы.
Единственной, отличительной чертой реальной гибкости и адаптивности - является ритм Ретроспективы. До главы "План управления улучшениями" свода Знаний (PMBoK) мало кто дочитывает. Некоторые компании проводят "разбор полетов", особенно, если было ЧП. И тогда у них Agile уже есть. Некоторые внедрили СМК и тогда у них по регламенту есть какие-то процедуры улучшения и пересмотра.
Иван: А можешь пояснить фразу "Единственной отличительной чертой реальной гибкости и адаптивности является ритм Ретроспективы."
Т.е. регулярные ретро = agile, не регулярные = не agile?
Алексей: Можно сказать и так.
По хорошему Agile software development (ASD)- это противостояние контрактных обязательств и адаптивного, уточняющего подхода. Но перекладывая ASD в другие отрасли мы теряем важное: у нас нет высокой неопределенности или нет объединяющей цели .
Приведу примеры отличий:
- В стройке - этап конструирования 1-2 года, в разработке ПО - 1-5 минут (сборка проекта и получение исполняемого файла)
- В маркетинге - нет цели вообще, сплошное экспериментирование, то есть регулярная работа в процессе.
- В продажах - даже экспериментов нет, если цикл сделки фиксирован. Если это сложные B2B продажи, то они строятся по процессу “планирование и экспериментирование” с уточнением стратегии. Но в любом случае тут нет цели спринта, вокруг которой собирать команду и “Заказчика"
Вот смотри, покажу на примере. В любой компании есть ДВА потока:
Поток создания ценности, которым все умеют управлять и корректировать (план-фактный анализ и тд), он обеспечивает адаптацию компании под рынок и изменяющиеся условия внешней среды, и
Поток управления - а про него забывают, это бизнес-процессы, у которых тоже есть метрики которые можно корректировать и которым нужно управлять.
Agile явно прописывает правила работы во вторым потоком обеспечивает рост компании и её развитие. Про второй поток вспоминают только когда "Что-то у нас исполнительская дисциплина снизилась" или "Производительность надо повысить", то есть редко и эпизодически.
В этим правилам я отношу:
- ритм Ретроспективы - напрямую влияет на второй поток
- правила работы с Заказчиком - влияет косвенно за счет управления ожиданиями и управление вовлеченностью Заказчика.
Давай, покажу на картинке:
Уж какая есть, это из нашей презентации решения.
Иван: А какие в agile есть метрики, которых нет в проектном управлении? Пример можешь привести?
Алексей: В том то и дело, что они все есть в проектном управлении! Или они выводятся исходя из целей, например: график "настроения команды".
Иван: Я правильно тебя понимаю, что очень многое на свете - есть agile. И лишь немного agile-ом не является? Вот проектное управление в грамотных руках - agile. Управление хирургическим отделением в стационаре (там регулярные ретроспективы каждое утро) - agile. И так далее?
Алексей: Да, именно так!
Компания по определению не может быть "не agile" она просто помрёт тогда. Потому, что нужно адаптироваться, рынок меняется, сезонность влияет, клиент меняется. У кого-то процессы отточены до совершенства управляемого уровня CMMI-4 и улучшаемого CMMI-5, а кто-то действует по наитию на уровне CMMI-1 адаптируясь, когда совсем прижмет (идем к врачу когда зуб уже болит).
Если смотреть в корень, то в американских компаниях были (и сейчас есть) распространены кубиклы, а у нас такого количества перегородок вообще никогда не было, максимум кабинет на отдел, и кубикл на сектор (если повезет). Это разница культуры индивидуализма и культуры сообществ (землячество)
И это важно, поэтому у нас нет ломки "личного пространства", и уже есть высокий уровень командной поддержки, поэтому часто, не нужны утренние планерки.
Иван: Я понял. Спасибо. Но тогда термин agile очень сильно девальвируется.
Алексей: Да! Но его пихают везде. Это хороший бренд, который продается. Однако, знакомясь с компанией я спрашиваю "А вам зачем Agile?" и "Что беспокоит собственника? На что жалуетесь?" - и в первую очередь выстраиваю систему управления отменяя лишние или улучшая нужные правила.
Agile software development - это конкретный способ достижения конкретных результатов в конкретной сфере. А чтобы он заработал, нужно создать экосистему. У этого способа есть ограничения которые находятся выше него (например много-клиентская среда). И где включаются инструменты проектного управления и Теории ограничений (ТОС)..
Если сменить сферу - остается только ритм PDCA и нужно иметь ответы на вопросы "А что будет означать эта практика в этой области?"
На этой ноте нам пришлось прерваться.
Комментариев нет:
Отправить комментарий