Автор заметки: Джон Катлер (John Cutler). Оригинал опубликован здесь.
Пару лет назад ко мне заезжал родственник (CEO страховой компании), которому успешно продали красивую идею Agile. Он поверил в нее и вскоре облажался: «Все это сплошная симуляция и обман! Мы изменили практически все в том, как мы работаем. Мы привели консультантов. Мы наняли звездных проектных менеджеров. И ничего, ни-че-го! Вообще ничего не изменилось. И никакой ответственности за результат: все, что я слышу – это отговорки и оправдания».
Не помню, что я ответил ему тогда, но я знаю, что бы я ответил сегодня. Я бы нарисовал пару картинок и даже не стал бы упоминать слово “Agile”.
Эффективность потока
Если разобрать Lead Time, можно заметить, что большая часть времени тратится на ожидание. 15-процентное соотношение времени работы (work time) к общему времени выполнения задачи (lead time) – это нормально. Лучшие достигают показателя в 40%.
В то время, как большинство команд концентрируются на сокращении времени работы (work time), секрет успеха кроется в сокращении времени ожидания (waiting time).
Источник: Hackernoon
Незапланированная работа и переключения
75% времени сотрудники теряют на незапланированную работу и переключения с одних задач на другие. Столь ужасающие факт остается в тени и, конечно же, не отражается в учетных системах, но изо дня в день изводит всех участников. Теперь представьте, что речь о “shared service”, и команда разработчиков также занимается эксплуатацией. Незапланированные работы могут вовсе парализовать всю проектную деятельность.
Источник: Hackernoon
S, M и L
Посмотрите на время выполнения больших, средних и маленьких задач. Скорее всего, вы заметите, что во многих организациях размер задачи никак не связан со временем ее выполнения. Почему? Слишком много факторов влияет на то, как долго выполняется работа: взаимные зависимости, незапланированная работа, большое количество задач, одновременно находящихся в работе и так далее.
Источник: Hackernoon
Получение выгод
Титанические усилия мы тратим на то, чтобы снизить так называемый проектный риск (delivery risk) (своевременно и в полном объеме). Это имеет смысл, если мы занимаемся разработкой уникального продукта и заказчик платит нам по факту его предоставления. Но взглянем на услуги типа SaaS (software as a service): факт оплаты не привязан к факту завершения работ над услугой, а выгода потребления услуги для заказчика проявляется со временем. Поэтому уместнее говорить о риске неполучения выгоды (benefit risk) – результат работы не будет востребован.
Большие компании применяют agile, но не видят никаких финансовых преимуществ. Почему? Разработка идет быстрее, но это никак не связано с: а) правильными решениями по развитию продукта; б) работой по пониманию выгод заказчика.
Многие применяют agile, как показано на картинке слева. Единицы следуют тому, что показано справа. Когда компании получают убогие результаты, они пытаются впихнуть в систему еще больше работ, делая всех еще более несчастными.
Источник: Hackernoon
Неуправляемый рост сложности
И наконец. Без целенаправленного управления сложностью, рефакторинга, автоматизации, реализация одной и той же фичи в следующем году займет больше, чем в этом. Даже если команда останется прежней. Рост времени реализации с трех дней до шести недель – к сожалению, не страшный сон и не фантастика.
Источник: Hackernoon
Agile
Так вот на счет Agile. Agile бесполезен до тех пор, пока не используется как катализатор постоянного совершенствования. Забудьте Scrum и SAFe, если не готовы играть в долгую. Факторы, которые замедляют работу, только частично зависят от того, “спринуете” ли вы, пишете ли user stories и готовите ли каждые две недели новые демки или нет. Рискну заявить, что все это сравнительно малозначимо с тех пор, как вы прониклись идеей инкрементального снижения риска.
Чтобы “быть agile” по-настоящему, потребуется куда больше:
- Делать работу, которая действительно значима (с точки зрения выгод). Делать меньше.
- Прояснить поток создания ценности.
- Автоматизировать pipeline (DevOps).
- Менять культуру.
- Перестать привлекать деньги под проекты, привлекать деньги на реализацию миссии (mission-based funding)
- Перераспределять ресурсы для управления сложностью (проводить регулярный рефакторинг).
Никакой серебряной пули. Здесь по-прежнему много работы. Опасайтесь тех, кто говорит обратное.
Срочно позовите евангелиста!