На сегодняшний день Scrum является наиболее популярным фреймворком среди всех методов Гибкой Разработки ПО (Agile Software Development). Это видно по тому, о чем чаще всего говорят в статьях и на конференциях, также популярность подтверждается результатами опросов.
В то же время, все больше компаний сталкиваются с ситуацией, когда у вас есть сразу несколько команд, работающих над одним продуктом или проектом. Очевидно, что “Простой Ванильный Скрам” (plain vanilla scrum) тут не подходит. Конечно, Кен Швабер давно уже упомянул “великую мудрость”: Скрам-Скрамов (Scrum of Scrums) – встречу синхронизации между командами. Но на практике, одна эта встреча не помогает решить все вопросы организации масштабного проекта и координации 2-х и более команд. Во всяком случае исходя из моего опыта 😉
Последние года три, я постоянно сталкиваюсь с такими крупными проектами и компаниями, которые создают Enterprise Agile методы и культуру. Чаще всего решения, как все организовать, мы принимаем на основе тех же Agile и Lean принципов, а в основу работы команд берутся известные практики из того же Scrum, плюс простые общеизвестные методы из менеджмента и совместной командной работы.
И все-таки, порой очень тяжело объяснить, как это все должно вместе работать людям из высшего менеджмента, собственно, принимающим решения. Да и просто обучить команды основным Agile методам и подходам становится нелегко. Ведь Agile методы лежат в поле эмпирических практик. Практикуясь, людям необходимо приобрести некоторый опыт, чтобы осознанно менять свои практики. Если одной команде в 5-9 человек требуется относительно небольшое время, чтобы осознать, как именно они работают вместе, то представьте, что происходит когда у вас одновременно 50 и более человек?
Несколько лет назад все чаще стал упоминаться Масштабированный Гибкий Фреймворк – Scaled Agile Framework или, как часто пишут: SAFe. Для меня он стал просто упорядоченным описанием того, что я уже применял или наблюдал – похожая ситуация у меня была в свое время со Scrum методом. С другой стороны я был рад, наткнувшись на внятное и целостное описание методов и практик, которые позволяют запустить масштабный проект, а точнее целую программу проектов. При этом будучи по-прежнему основанный на Agile и Lean принципах, этот подход позволяет скоординировать работу целой группы команд. И что самое важное, на мой взгляд, позволяет менеджменту делать некие прогнозы и планы, исходя из скоординированной работы команд. Поверьте, при всем уважении к Agile культуре в команде, на уровне бизнеса по прежнему стоят вопросы “Когда?” и “Сколько стоит?” 🙂
Чтобы объяснить, как все вместе работает, я предлагаю вам посмотреть короткое видео, сделанное одним из консультантов, внедряющих SAFe. В своем 7-ми минутном видео он подробно рассказал, как все работает и обозначил основную терминологию
[youtube http://www.youtube.com/watch?v=RXzurBazN-I]
Если вам интересны подробности этого подхода или мои советы по этой теме, дайте мне знать, пожалуйста, в комментариях.
Оставайтесь с нами, я постараюсь вернуться к регулярному графику публикаций, так как все больше и больше хороших людей просят меня об этом 🙂
Тут же не могу не ответить вот таким постом от agile42 http://www.agile42.com/en/blog/2014/03/28/safe-and-unsafe-words/
Что думаешь?
Андрей, спасибо за ссылку – хорошая подборка разных статей. Правда, на мой взгляд, немного однобокие статьи с критикой SAFe.
Причем критикой от людей, которые “слышали” про подход, но никто еще не пробовал внедрять – в лучшем случае “прошли тренинг”.
На мой субъективный взгляд, это Фреймворк, такой же как Scrum, только более масштабный. Точно такие же вопросы возникают при обучению Scrum – люди скептически относятся к новым практикам. И часто, когда копают глубже с вопросами “а что нам делать в ситуации Х”, то тут либо выручает практический опыт тренера в таких ситуациях (тогда будет ответ вида “можно попробовать Y или Z”), либо будет абстрактный ответ “это зависит от ситуации”.
Один в один ситуация повторяется и с SAFe… По нашему опыту внедрения, фреймворк покрывает только самые ключевые практики. Дальше уже организация строит свой набор принципов и практик.
Если читать тренинг, который дает общее представление про SAFe, то остается куча белых пятен. Точно также, как Scrum ничего не говорит про организацию команды и улучшения совместной работы, и также, как этот популярный метод, молчит о работе с требованиями.
Более того, меня слегка умиляет комментарий про “True Agile”, в то время как сам Швабер говорит, что в 70% случаях Scrum делается неправильно и превращается в разновидность command-and-control и формального процесса.
Однозначно SAFe не “серебряная пуля” и не решает всех проблем. Да, как кто-то правильно сказал “он снижает порог входа в Agile методы для крупных компаний”. На мой взгляд это отлично! Так как главным препятствием для распространения Agile в организации, уже который год подряд признают сопротивление культуры и отсутствие поддержки менеджмента. Если мы, как индустрия, сможем растопить этот лёд, то в ближайший десяток лет сможем увидеть революцию ИТ-индустрии в корпоративном секторе 🙂
Но все, как обычно, зависит от людей, которые будут внедрять методологию и пропагандировать или наоборот “поливать грязью” ее. Именно поэтому, я считаю неприемлемой критику метода от тех, кто его не практиковал и даже толком не изучал. Особенно, когда люди типа Дэвида Андерсона, с милионном читателей, высказываются в стиле: “я с SAFe особо и не разбирался, но считаю его ересью”. Это говорит о многом… во всяком случае о характере Дэвида 😉
Вот такое краткое ИМХО.