Данная статья — это попытка описать мои мысли от Agile-подхода, его модификациях и проблемах, рассказать про то, как смотреть на Agile с позиции операционного менеджмента и дать решение проблемы применения метода на крупных предприятиях.
Я, Влад Свяжин, руководитель проектов в «Дататех» (Холдинг Т1), уже давно работаю в IТ в проектном управлении, получил сертификаты по основным проектным подходам (PMP, MSP, SAFe). На проектах мне часто нужно рассказывать про различия между «ватерфолом» и «аджайлом», долго обсуждать различные вариации и проблемы с Agile вместе с заказчиком и командой. Я хотел найти хорошую статью или запись на YouTube, чтобы можно было избежать этих долгих обсуждений и заранее всех познакомить с понятиями, но ничего не нашел. Если вы знаете, поделитесь в комментариях.?
Эта статья родилась, когда готовились материалы к конференции ШСМ (Школа системного менеджмента).
Введение
Все знают, что это такое Agile. Он начал распространяться после публикации манифеста, где были описаны основные принципы Agile. В течение быстрого времени он захватил умы своей простотой и стал любимым способом делать проекты в IТ. Конечно, ведь там же можно ничего не документировать и не планировать
Я лично сталкивался с этим и не раз слышал фразу «мы работаем по Agile, поэтому мы ничего не документируем». Понятно, что «расхлябанность» и свобода Agile должна была привести к ответам со стороны всевозможных коучей, бюрократии и корпораций.
Первый ответ - классификация проектов и попытка предположить, где можно применять Agile, а где нет. Примеры классификаций проектов из https://habr.com/ru/post/193232/.
Чем ближе мы к середине, тем вероятнее выберем Agile как проектную методологию. В среде проектных управляющих появились фразы похожие на следующее утверждение: нельзя выбирать Agile, если вы работаете с государством, аутсорсингом, консалтингом. С этим успешно борется Entrprise Agile Russia и убеждает, что можно быть Agile и в государственных проектах.
Второй ответ - добавление внутрь Waterfall Agile-подходов или наоборот. Например, в своем докладе «Варианты и примеры гибридизации Agile и классических подходов» Павел Алфёров показывает, как можно взять лучшее из двух разных методологий. Waterfall после гибридизации становится более «продвинутым» и «современным».
Третий ответ – это добавление дисциплины в Agile, такой подход так и называется Дисциплинированный Agile - Disciplined Agile (DA).
У больших корпораций, конечно, есть свой путь, примером которого является «Банкоджайл». Основные принципы отлично описаны в этом манифесте WWW.HALFARSEDAGILEMANIFESTO.ORG.
Приведу перевод этого замечательного документа:
Люди и взаимодействие важнее процессов и инструментов
и у нас есть обязательные процессы и инструменты для контроля того, как эти люди взаимодействуют (мы предпочитаем термин ‘ресурсы’)Работающий продукт важнее исчерпывающей документации
до тех пор, пока это продукт всесторонне документированСотрудничество с заказчиком важнее согласования условий контракта
конечно, в рамках строгих контрактов и при условии строгого контроля измененийГотовность к изменениям важнее следования первоначальному плану
при условии, что имеется подробный план реагирования на изменения, и он точно соблюдается
Хотя пункты слева в теории хороши, но мы крупная компания и мы никогда не откажемся от пунктов справа.
Больше про манифесты почитайте здесь.
Основная часть
Получается, все перемешалось в «аджайл/ватерфол/банкоджайл», и нужен взгляд не со стороны коучей по Agile, а с другой. Поэтому я дам объяснения со стороны операционного менеджера. Рассказ про то, как и зачем нужны вьюпоинты, можно почитать на курсе «Системное мышление» Анатолия Игоревича Левенчука. Для простоты понимания, я буду приводить примеры и метафоры с перевозкой людей, это удобная для моего объяснения модель, но, как и любая модель, обладает своими ограничениями.
Сначала упростим и представим, что любой проект состоит из фич, которые нужно провести по всем этапам жизненного цикла. Метафора - у нас есть пассажиры, которых нужно перевести из города Замыслено в Спроектировано, потом в Реализовано, в Протестировано, и наконец в Эксплуатацию. Модель хороша тем, что у пассажиров, как и у фич, есть сложные взаимосвязи между собой. Это могут быть семьи и их нельзя разъединять или спортивная команда, выступающая вместе на соревнованиях. В общем, у всех разные приоритеты и нужное время прибытия. Waterfall говорит о том, что можно сразу все замыслить, потом все спроектировать, реализовать, протестировать и передать в эксплуатацию. И это будет работать, как мы изначально замыслили. И, конечно, с первого раза правильно — это как раз про такой подход.
Раньше «водопадную» разработку рисовали стрелками из конца одной стадии к началу следующей.
Через некоторое время стало понятно, что это не работает, и этапы накладываются друг на друга, несмотря на желание и требования менеджеров. И если менеджеры слишком требуют «водопад», то исполнители просто не говорят, что стадии перехлестываются. Даже на картинках стали изображать их «перехлестывание», и что окончание одной приходит куда-то в середину следующей стадии.
В книге Дональда Райнертсена «The Principles of Product Development Flow: Second Generation Lean Product Development» приводится аналогия о принципе раньше используемом в американской армии «Не говори/Не спрашивай». Все понимают, что бывают и будут переделки. Первоначальное ТЗ нужно менять по результатам проектирования, но об этом не говорят и не спрашивают.
Вернемся к нашей модели. Соберем всех пассажиров, посчитаем, внесем в журнал и будем перевозить из города в город строго по записям этого журнала на огромном поезде. Конечно, начнутся проблемы в том, что фичи как и люди плохо планируются все вместе, часть станет ненужными в процессе, часть не поедет на следующую станцию, часть появится уже в конце проекта с просьбой их перевезти и перевезти их нужно обязательно. Бизнес не будет стоять на месте и ждать, когда часть людей сойдет на остановке и не вернется. Верить, что только те, кто купил билеты заранее будут ехать по всему маршруту — это наивность, как и вера в настоящий «водопад».
Чтобы все-таки возить, и «водопад» был реалистичным, начали вводить запросы на изменения - трудоемкие процедуры, с оценками, согласованиями и прочим. Можно сказать, что запустили отдельно от нашего огромного поезда дополнительные маленькие поезда, которые добирали пассажиров, что появлялись на станциях после того, как большой поезд ушел.
Логично, что нужно работать по-другому. Если Waterfall можно сравнить с большим поездом, который долго набирает пассажиров на каждой станции и потом их везет, то Agile – это попытка уменьшить размер этого транспортного средства. Хороший пример: SCRUM, который говорит, что возить мы будем на маршрутке, вмещающей ровно столько фич, чтобы она успела проехать за время спринта (1-2 недели). Тогда у нас меньше проблем с тем, что фичи устареют, а бизнес будет сажать в маршрутку самых приоритетных пассажиров. Вот он наш Agile-подход: все довольны, пассажиры ездят на маршрутках, все гибко. Так почему так сильно критикуют эти методы? Почему в мире не победили маршрутки, а все еще есть другие средства передвижения?
Ответ операционного менеджера в решении логистической задачи - каким будет оптимальный размер количества пассажиров, перевозимых за раз.
У нас есть две переменные:
Первая — это Затраты на Задержку, и эта переменная будет в общем виде линейно (можно упростить) расти в зависимости от размера батча/количества пассажиров. Чем больше фич/пассажиров мы вставим в батч/маршрутку, тем дольше он будет делаться/ехать, тем больше затраты на задержку. Чем больше людей будем ждать, тем дольше маршрутка будет набирать пассажиров.
Вторая — это Транзакционные Затраты. В нашей метафоре, это транспортные затраты на водителя, на бензин, на обслуживание маршрутки и прочее. И эти затраты будут снижаться в пересчете на одну фичу/пассажира за переезд. Например, если мы перевезем одного пассажира, то все затраты будут делиться на него одного. Если их будет двое, то разделим на двоих и так далее.
Для проекта это интеграционные затраты - нам нужно все тестировать при каждой установке, затраты на написание и согласование документации. Например, если мы пишем и потом согласовываем на каждый релиз описание доработок системы, тогда чем больше фич мы вставим в этот документ, тем лучше.
Оптимальным решением этой задачи будет наименьшая точка на графике Общих затрат. С одной стороны, она удовлетворит бизнес, который относительно быстро и главное дешево получит свои фичи, а с другой - удовлетворит релиз-менеджера и команду, которая не будет писать много документов.
Пример: у нас есть одинаковые средства передвижения - маршрутки с одинаковыми транспортными затратами, но разными затратами на задержку (условно маршрутка обслуживает VIP бизнес-форум или обычный маршрут), тогда оптимальный размер количества пассажиров для очень больших затрат на задержку/VIP-форума может быть один пассажир, а для низких - полная маршрутка.
Пример: у нас есть одинаковые пассажиры при равных затратах на задержку, но разные средства передвижения с разными транспортными затратами, тогда оптимальный размер для маршрутки с маленькими транспортными издержками может быть 6 человек, а для поезда - 200 человек.
В книге Дональда Райнертсена говорится, что большие батчи это плохо, а маленькие это хорошо. Кратко перечислю принципы из книги:
B1: The Batch Size Queueing Principle: Reducing batch size reduces cycle time.
Уменьшение размера батча уменьшает время цикла. Значит мы сделаем больше итераций, а так как подразумевается, что мы будем обучаться на каждой итерации, то все показатели будут расти. Узнали, как лучше ездить по маршруту и где можно, а где нельзя срезать.
B2: The Batch Size Variability Principle: Reducing batch sizes reduces variability in flow.
Уменьшается вариативность – улучшается предсказуемость. Мы сможем лучше предсказывать, когда заполнится и приедет наша маршрутка с 5 пассажирами, чем с 50.
B3: The Batch Size Feedback Principle: Reducing batch sizes accelerates feedback.
Мы раньше сможем получать обратную связь. Побывав в пункте Эксплуатация, наши пассажиры сразу позвонят и расскажут остальным, кому нужно быстрее туда поехать.
B4: The Batch Size Risk Principle: Reducing batch size reduces risk.
Уменьшение размера батча уменьшает риски. Ведь с меньшей вероятностью что-то произойдет с одним из пяти пассажиров, чем с одним из пятидесяти.
B5: The Batch Size Overhead Principle: Reducing batch size reduces overhead.
Уменьшаются перегрузки системы и увеличивается эффективность. Одно дело, если попался полицейский и ему надо проверять документы у 10 маршруток по 5 человек в разное время, другое дело, когда в одной сразу 50 пассажиров. Он будет полностью загружен в этот момент и не сможет заниматься чем-то еще, а все 50 человек будут ждать конца проверки.
B6: The Batch Size Efficiency Principle: Large batches reduce efficiency.
Большие батчи ухудшают эффективность.
B7: The Psychology Principle of Batch Size: Large batches inherently lower motivation and urgency.
При больших батчах срабатывают психологические законы, которые уменьшают мотивацию и срочность. Зачем сильно стараться и спешить сесть в поезд, если он отъедет только через неделю, а вот в отъезжающую маршрутку можно и побежать, чтобы успеть.
B8: The Batch Size Slippage Principle: Large batches cause exponential cost and schedule growth.
Большие батчи приводят к экспоненциальному росту затрат и времени.
B9: The Batch Size Death Spiral Principle: Large batches lead to even larger batches.
Большие батчи приводят к еще большим батчам. Так называемая «спираль смерти» огромных проектов.
B10: The Least Common Denominator Principle of Batch Size: The entire batch is limited by its worst element.
Весь батч ограничен его худшим элементом.
Если будут комментарии и запросы, то можно их подробно раскрыть в отдельной статье.
Значит нам нужно перейти от больших батчей к меньшим. Так как наши затраты на задержку не меняются, то чтобы передвинуть оптимум влево, нужно уменьшить наши транзакционные издержки.
Значит, чтобы уменьшить размер оптимального батча, нужно уменьшать транзакционные затраты.
Давайте теперь еще раз посмотрим на принципы Agile из Agile-манифеста:
Люди и взаимодействие важнее процессов и инструментов;
Работающий продукт важнее исчерпывающей документации;
Сотрудничество с заказчиком важнее согласования условий контракта;
Готовность к изменениям важнее следования первоначальному плану.
И представим небольшую команду, работающую над кодом, ну или нашу любимую маршрутку, которой нужно перевести из Замыслено-сити в Эксплуатацию-град. Попробуем применить принципы Agile для водителя маршрутки.
Попросили остановиться на перекрестке, маршрутка сразу остановилась. Это удобно водителю, который может ехать дальше и взять еще кого-то, и пассажиру, ему меньше идти до дома.
и 3. И не важно, что было написано в инструкции, что останавливаться можно только на остановках. Так удобнее и лучше.
Если водитель видит, что впереди авария и ее можно объехать, то он может обсудить это с пассажирами и изменить маршрут.
Все становится очень удобно для пассажиров, которые быстрее доезжают до нужной точки, а не до официальной остановки, и водителю, который может быстрее проехать маршрут и перевезти больше довольных пассажиров. Изменение мышления водителя привело к замечательным результатам - Agile работает! Значит мы, просто изменив мышление, уменьшили наши транзакционные затраты, точка на графике сдвинулась, и оптимальным стал меньший размер батча.
А теперь давайте представим большой поезд/корпорацию/банк, и к нему приходят Agile-коучи, которые недавно перестроили водителя маршрутки, прочитали классные статьи и убедились, что изменением мышления можно добиться результатов. Мы начали внедрять Agile в мышление машиниста поезда. Они предлагают останавливаться по требованию любого пассажира, по факту поезд будет дольше стоять, чем ехать, или менять маршрут и время по договоренности между машинистом и первыми пассажирами, но все остальные пассажиры/другие машинисты не будут понимать, когда какой поезд выедет и приедет. Получается, внедрение Agile и его подходов не приведет к уменьшению транзакционных расходов, а приведет к бардаку и хаосу. Именно из этого бардака и родились все наши ответы на «расхлябанность» Agile, перечисленные в введении.
Еще раз: машиниста поезда сверху заставляют водить поезд как маршрутку, и все примеры успеха дают из маршрутной истории, но требуют результативности лучше, чем было раньше.
Есть ли другой подход? Конечно, и эти ответы давно даны в литературе. Например в книге DevOps for the Modern Enterprise by Mirco Hering
Чтобы уменьшить транзакционные затраты, нужно вложиться в инфраструктуру: автотесты и DevOps. В нашем случае мы должны не только изменить с помощью Agile мышление машиниста, но и перейти с инфраструктуры поездов (релиз раз в квартал) к маршруткам (раз в 2 недели). Вот тут и может появиться наш «любимый» SCRUM с его длительностью итераций. Статью про проблемы SCRUM я напишу, если будет заинтересованность к текущей статье.
Получается Agile хорош и отлично применим, если есть правильная инфраструктура. Для маленьких команд даже изменение мышления даст результат, но если перед нами что-то среднее или большое, то только инвестиции в инфраструктуру, автоматизированное тестирование и DevOps вместе с изменением мышления дадут результат.
Кратко подведем итоги:
Проект — это набор фич, которые нужно провести по стадиям жизненного цикла.
Waterfall — это подход, когда мы переносим все фичи по стадиям жизненного цикла за раз, Agile-подходы мы несем итеративно часть фич/батч.
Оптимальным размером батча является точка с минимальной суммой транзакционных затрат и затрат на задержку.
Лучше нести маленькими батчами, так как будем гибче и быстрее получим обратную связь, чтобы совершенствоваться.
Чтобы оптимальным размером стал меньший батч, нужно уменьшать транзакционные издержки.
Если у нас маленький и простой проект, то можно уменьшить транзакционные издержки, изменив мышление команды с помощью принципов Agile.
Если проект большой, нужно вкладывать и менять инфраструктуру - без этого внедрение только принципов Agile приведет к ухудшению ситуации и появлению гибридов.