Когда я прочитал: «Agile is much more than just Scrum» — в описании сертификационного курса Certified Agile Professional компании ScrumTrek, то первое, о чем я подумал: почему ScrumTrek, тогда уж нужно было назваться AgileTrek? После прохождения этого обучения я вернулся к этому утверждению с более серьезным настроем. Так что же я вынес с тренинга? Записи, раздаточный материал и сертификат Certified ICAgile Professional? А как же понимание, что такое Agile? В чем заключается концепция Agile-подхода? Что такое Agile mindset?
В этой заметке я делюсь впечатлениями о тренинге. Это не столько пересказ содержания тренинга, сколько субъективная оценка пользы полученных на нем знаний. Надеюсь, что это поможет определить, нужно ли вам это обучение.
История Agile
Хорошо запомнилась история Agile, которую тренер представил в виде поступательного взросления всей отрасли разработки ПО.
Code-and-Fix позволил стартовать отрасли написание кода относительно дешево без каких-либо планов, документации и специальных требований к квалификации разработчиков.
Ему на смену в 1970 годах пришла водопадная модель (Waterfall), которая снизила риски, повысила прозрачность разработки ПО, а также устранила проблему высокой стоимости сопровождения ПО при сохранении низких требований к квалификации разработчиков. Модель начали использовать повсеместно, что быстро обнажило и ее проблемы. Водопад хорошо работает только в тех случаях, когда заранее все известно: какой продукт необходимо разработать, какие технологии реализации нужно использовать – и никаких изменений по ходу не возникает.
Первые попытки исправить ситуацию связаны с появлением в 1990 годах итеративных подходов. С одной стороны, этому способствует удешевление компьютеров, когда машинное время перестает быть объективным ограничением, что позволяет производить многократные эксперименты по наращиванию функциональности продукта. С другой стороны, новые технологии ИТ все больше и больше усиливают конкуренцию, поэтому бизнесу приходится оперативно применять их в бизнесе. Кто внедрил новую технологию раньше остальных, то завоевал и клиентов, и рынок. С этого момента начинается активное развитие гибких процессов разработки, которые ставят своей целью предоставить бизнесу быстрые поставки функциональности. По сути происходит откат к «быстрому» методу Code-and-Fix, но его дополняют планированием и исключением рисков.
Кстати, мне кажется, что и по сей день большинство корпоративных разработчиков применяет вовсе не Scrum, как им кажется, а именно итеративный водопад. Посмотрите на схему ниже, у вас ведь как-то так все работает?
Или все же так, как в Scrum?
В 1992 году появляется Crystal, который впервые фокусируется на частой поставке работающего кода конечным пользователям. Затем в 1994 представлен DSM (Dynamic Systems Development Method), который провозгласил ориентацию на потребности бизнеса и неснижаемый уровень качества ПО (примерно в эти же года появился термин Refactoring). Наконец в 1996 году представлен Scrum Framework, который стал стандартом де-факто для управления гибкой разработкой. В этом же году начинает впервые применяться парное программирование. А в 1999 появляется XP, который принес концепцию пользовательских историй (User Story), планирования релизов и непрерывной интеграции (Continuous Integration). Итогом всех этих частных инициатив стал разработанный в 2001 году Agile-манифест разработки программного обеспечения, в котором закреплены проверенные 10-летием ценности и принципы, позволяющие быстро поставлять функциональность бизнесу.
Дальнейшее развитие Agile связано с попытками устранить все возможные потери (простои) в процессе разработки ПО, за счет чего еще больше повысить скорость доставки функциональности. В 2003 появляется Lean Software Development как адаптация концепции бережливого производства Toyota к отрасли разработки ПО. В 2006 движение продолжается за счет появления Kanban Software Development, в котором представлен готовый алгоритм устранения потерь в потоке поставки ценности (функциональности) бизнесу. Также в 2011 году в ответ на взрывной рост SAAS (ПО как сервис) появляется концепция DevOps, которая объединяет разработку и сопровождение для устранения потерь на их стыке.
Итого, производство (разработка) перестало быть узким звеном, научившись максимально быстро удовлетворять потребности бизнеса. Тем не менее, развитие Agile продолжается. Во-первых, в области масштабирования Agile на крупных предприятиях (SAFe). Во-вторых, огромное количество провальных инвестиционных проектов поднимает вопрос в области разработки продуктов: как максимально дешево разработать максимально востребованный продукт? В 2009 году ответом на это ограничение становится Lean Startup.
Как вы думаете, что будет дальше? Мне кажется, что в ближайшем будущем неизбежно изменение системы образования, так как процессы исполняются не сами по себе, а людьми.
Ценности и принципы Agile
Совместно с участниками тренер последовательно и глубоко разбирает каждую ценность и каждый принцип Agile-манифеста разработки программного обеспечения. Признаюсь, что до тренинга я искренне полагал, что отлично понимаю ценности и принципы. Оказалось, что это не совсем так.
К примеру, вторая ценность Agile: «Работающий продукт важнее исчерпывающей документации». В свое время это было декларацией отрицания водопадной модели, в которой понимание прогресса во многом опирается на проектную документацию. Но во 2 версии Agile-манифеста формулировка изменилась: «Бизнес-ценность важнее работающего продукта» (Agile Manifesto 2.1 — «MoreAgile Manifesto»). Это пример эволюции Agile-ценностей связанный появлением Lean Startup: слишком много работающих продуктов оказывались никому не нужными.
Scrum и Kanban
Значительную часть тренинга занимает обзор Scrum Framework и Kanban. Пересказ этой части тренинга не входит в цели данной заметки. Отмечу только, что каждый нетривиальный момент тренер помогает прочувствовать на кончиках собственных пальцев посредством командной игры. А вот об этом стоит рассказать подробнее.
Игры в Agile
Все игры были простыми в освоении и веселыми в процессе. Во время одной игры на второй день тренинга один из участников воскликнул: «И чем мы раньше занимались? Вот оно!» Ниже я расскажу о том, чему мы научились в играх.
Penny/Multitasking games вживую (на нас самих) и убедительно (обычным секундомером) продемонстрировали необходимость брать в работу малые порции и не выполнять в один и тот же момент времени несколько задач. Мы увидели, как это исключает потери из-за простоев в строго последовательном процессе работы (водопад), потери из-за накопления незавершенной работы (набитый рот дольше жует) и на переключения контекста (в водопадной модели работа сотрудника над несколькими проектами одновременно наиболее вероятна).
Planning pocker настолько простая техника командой оценки, что даже в рамках недолгой игры позволяет прочувствовать свои достоинства. К примеру, все члены моей игровой команды согласились в итоге, что большую часть времени мы потратили вовсе не на оценку трудозатрат той или иной работы, а на обсуждение работ, которые мы понимали изначально по-разному. Иными словами, основная польза заключается вовсе не в цифре оценки, но в одинаковом понимании работы. С другой стороны, будучи ограничены по времени, мы избегали споров и обсуждений, если наши оценки сходились сразу же. Простые вещи, но как нелегко им следовать в работе! Не правда ли?
Игровая постановка саботирования Daily Standup Meeting вернула нас к обсуждению ценностей Agile. К примеру, Scrum Master (процессный коуч) не должен быть менеджером для команды разработки или вести себя соответствующим образом, то есть раздавать задачи, включать эмоции и противопоставлять себя группе, превращая тем самым встречу в унылое отчетное собрание членов команды перед самим собой.
Ball Point game показала как работает командная динамика. Как и ранее, подопытными кроликами являемся мы сами (это значит, что ты все чувствуешь, а не только наблюдаешь), а цифровые результаты достаточно убедительны. Что мы поняли?
- Команды большего размера эволюционируют медленнее, так как с ростом количества членов команды усложняются коммуникации.
- Наибольший прирост производительности дает изменение принципа работы, а не призывы: «Давайте поднажмем! Соберись, тряпка!»
- Важнее быстрее запускать предложения по улучшению в эксперимент, нежели долго искать идеальное решение.
Заключение
И, как? Теперь вы понимаете, что такое Agile? Если нет, то рекомендую посетить тренинг. Если да, то рекомендую притащить на тренинг всю свою команду, особенно, если вы только стартуете в ней Agile.