Философия agile что это: Гибкая методология разработки — Википедия – Как Agile философия помогает создать эффективную команду : Энциклопедия результативного маркетинга

Как Agile философия помогает создать эффективную команду : Энциклопедия результативного маркетинга

или останься в прошлом

Современный мир меняется с большой скоростью. Если Вы не будете меняться вместе с ним — то очень скоро безнадежно устареете. Но как успевать за переменами? Решение найдено: это Agile философия. О ней мы сегодня и поговорим.

Как появилась Agile философия?

Многие производственные компании и компании из сферы услуг часто задумываются о том, как выстроить эффективный процесс работы команды и повысить качество конечного продукта. Задумываются обычно тогда, когда понимают, что продукт получается хуже, чем планировалось, не соответствует ожиданиям клиентов, выбивается из сроков и бюджетов.

В 2001 году 17 практиков современных подходов со словами: “Хватит это терпеть”, собрались на горнолыжном курорте Snowbird, что находится в горах Юты, для обсуждения вопросов управления и обмена опытом. И тогда они поняли, что подходы у всех разные, но идеи совпадают. Так на свет появилась формула Agile, а в последствии и прикладные решения SCRUM и Канбан.

Agile — это философия, образ мышления и культура. Agile содержит в себе 4 фундаментальные идеи, которые дополняют 12 принципов.

Идеи и принципы описаны общими фразами, сходу их понять и сразу внедрить у себя сложновато, но если Вы будете регулярно им следовать, то Ваш продукт станет лучше, команда эффективнее, а Вы — счастливее. Далее на примере, перечисляя идеи из манифеста Agile, я постараюсь сравнить традиционное digital-агентство с агентством, которое работает по Agile. А выводы делайте сами.

Идея №1: Люди и взаимодействия важнее процессов и инструментов

Традиционное: процесс разработки и согласования дизайн-макета сайта с Заказчиком достаточно сложный.

Сначала разрабатывается ТЗ, потом дизайнер разрабатывает дизайн-концепцию, согласовывает с руководителем отдела, затем с руководителем проекта, затем с Заказчиком, после этого рисуется дизайн и согласовывается по тому же кругу.

Затем вносятся правки, еще правки и в лучшем случае получается результат. А в худшем это продолжается до тех пор, пока у Заказчика и команды работающей над проектом попросту не останется сил и терпения, на правки закрывают глаза, а проект уходит в верстку или вовсе замораживается.

Agile-команда: все, кто влияет на конечный продукт (например, Заказчик, дизайнер, менеджер проекта, маркетолог, программист, аналитик, директолог, таргетолог и конечный пользователь) собираются вместе перед началом этапа разработки дизайн-макета и общаются.

В ходе общения учитываются все идеи, анализируются возможные проблемы, собирается обратная связь. Далее запускается работа над проектом и общение всей команды происходит после каждой значимой итерации (например, после разработки дизайн-концепции, дизайна первого экрана, второго, третьего). После общения работа над проектом продолжается.

Итоговый дизайн-макет максимально учитывает мнения каждого и соответствует ожиданиям Заказчика.

Идея №2: Работающий Продукт важнее исчерпывающей документации

Традиционное: за месяц работы успели только согласовать и утвердить техническое задание, которое детально описывает несуществующий продукт и составить план-график проекта. Продукт еще не готов.

Agile-команда: встретились, обсудили задачи, расставили приоритеты и взялись за дело. От идеи до начала работы прошло 3 дня. В течение месяца команда выпускает бета-версию работающего продукта.

Идея №3: Сотрудничество с Заказчиком важнее проработки деталей контракта

Традиционная команда: юристы на стороне агентства и Заказчика дотошно проверяют договор, предусматривают все возможные риски. Целый месяц гоняют договор туда — сюда, обсуждают различного рода штрафы и неустойки. Все это вместо того, чтобы начать разрабатывать продукт.

Agile-команда: старается выстроить хорошие отношения с Заказчиком, ориентируется на win-win стратегию. Иными словами, при Agile-сотрудничестве абсолютно все находятся в одной лодке. При возникновении проблем не идут в суд, а встречаются лично и думают, как быть.

Идея №4: Готовность к изменениям важнее следования первоначальному плану

Традиционная команда: запланировали сделать для проекта 3 рекламных кампании в Яндекс.Директе.

Так получилось, что директолог, настроив одну рекламную кампанию, заболел и не может работать. Агентство ждет, когда директолог выйдет с больничного и доделает оставшиеся рекламные кампании.

Спустя время, когда кампании готовы к запуску, у Заказчика нет в кассе денег на рекламный бюджет, необходимо ждать поступлений.

Спустя еще время, когда рекламный бюджет пополнен, маркетолог проекта проанализировал ситуацию и понял, что рынок сильно изменился и необходимо срочно переключаться на продвижение проекта в соц.сетях. Все возвращается в исходную точку, начинается настройка таргетинга…

Agile-команда: не занимается гаданием на кофейной гуще. Уверена, что будущее предсказать невозможно и может произойти все, что угодно. Действуют по ситуации и не готовятся заранее.

Когда заболел директолог — запускают трафик на одну рекламную кампанию вместо трех запланированных. Готовы к изменениям на рынке и оперативно производят доработки продукта при каждой перемене.

Важно!

Agile-манифест рекомендует искать баланс в идеях и ни в коем случае не отказываться от планов, документации, типовых бизнес-процессов и инструментов.

В первую очередь руководствуйтесь здравым смыслом. Если процесс необходим, его нельзя уничтожать — это навредит компании.

Сомневаетесь что философия Agile Вам поможет?

Мир меняется с бешеной скоростью. Вспомните, как лет десять назад заходить с телефона в интернет было проблематично, а сегодня сайты адаптированы под мобильные устройства. Мы перестроили их вслед за изменившейся реальностью.

Так и в бизнесе, он тоже хочет успевать за изменениями, поэтому всё больше компаний переходят на Agile-философию. Agile помогает выпускать по-настоящему гибкие продукты и обеспечивает преимущество.

В этой статье я привел пример 4 идей Agile-философии — это ее основа.  О принципах и технологиях SCRUM и Канбан расскажу в следующей статье.

Успехов Вам и развития!

Руслан Матвеев,руководитель проектов

Статьи в тему

Размышления об Agile / Habr

The measure of intelligence is

the ability to change.

Albert Einstein

Предисловие

Представляю ИТ-сообществу “Размышления о Agile” или можно назвать данную статью так, “Agile, это все же философия или проектная методология?”.

Цель данной статьи — обсудить с ИТ-сообществом вопрос о Agile, который у меня возник после многолетней проектной практики, выводы и резюме, к которому пришел, по результатам анализа этого вопроса.

Сам Вопрос привожу несколько ниже, так как, чтобы к нему перейти, имеет смысл изложить некоторые доводы и выводы.

Похожие темы уже поднимались на Хабре в различных ветках обсуждения, так что вопрос насущный и имеет свою историю.

На мой взгляд большинство статей не дает однозначного ответа на мой вопрос, поэтому настоящая статья, возможно, будет интересна многим.

Несколько статей на Хабре по теме:

Кратко о предмете вопроса

Чтобы немного было понятно откуда “дует ветер”, отмечу, что мой опыт в ИКТ сфере более 10 лет. В самом начале карьеры активно трудился в телекоме, в софтверной разработке работаю сравнительно недавно, не более четырех лет.

На всем протяжении своей трудовой деятельности участвовал во всевозможных ИТ и Телеком проектах, в роли Руководителя проектов, последние годы был и бизнес-аналитиком, пробовал себя и в роли программиста. В результате краткого но объемного погружения в Java — development получил не большой, но все же, опыт самостоятельной разработки, прокачав технические скилл как младший-программист.

Сейчас же активно тружусь на ниве разработки программных продуктов как Руководитель проектов, опционально выступая как Бизнес — аналитика.

Таким образом предмет обсуждения этой статьи — это практика управления проектами по разработки программных продуктов, причем применительно именно к отечественной разработке.

Понимание вопроса автором

На протяжении своего проектного опыты в ИКТ, вывел для себя ключевое правило: управлять проектом с применением проектной методологии — хорошо, без методологии — непонятно.

В связи с выше озвученным пришел к необходимости изучения различных проектных методологии, методологий ITSM, разных бизнес-книг по теме, и просто “умных” и сложных книг.

С учетом популярности PMI в общем и моей родной телеком отрасли в частности, начал изучение с PMBoK. Хотя и не сразу был понят этот хитрый талмуд, не единожды при прочтении очередной главы мне приходилось задуматься над тем, что же всетаки курят составители книги. В итоге свод знаний был разложен на атомы и принят в полном объеме. К слову сказать, даже не однократно внедрен в ряде проектов с “пролетарским рвением”, терпением и проворством (внедрен не PMBoK конечно, а его инструменты).

Понимание PMBoK, приходит с опытом.

@PM


Кроме этого “эпичного” труда были исследованы и изучены другие методологии, были и просто авторы книг по проектному менеджменту (хотя такие личности как Т. Демарко, С. Беркун, С Макконел не просто авторы, а нечто все же большее), всех перечислять не имеет смысла, да и статья не об этом.

Подытожим, автор статьи в теме предмета, старается не отставать от мировых трендов, не забывает классику.

Deep dive in project management of Software

Заскучал в телекоме через восемь лет работы, и решив идти вперед, ринулся в ИТ.

Оказалось, что ИТ сфера не хочет жить в четких рамках классических “водопадов”, ГОСТ 34 не в моде, если конечно не брать в расчет Гос. сектор. Есть и другие тренды по управлению проектами, в мировом проектном менеджменте.

Agile-манифест не мог пройти мимо. Изучив ряд книг и пообщавшись с несколькими коллегами, решил, что Agile это, как минимум интересно. Но не совсем понятно как с этим работать в России, философия не дотягивает до методологии, а в нашей стране есть народная мудрость “что не запрещено, то разрешено”.

Как резюме: пришел к выводу, Agile конечно штука интересная, но все же, подходит пока больше для модных книг и небольших проектов, а как это внедрить на практике не ясно.

Анализ статей на Хабре, в общем-то, подтвердил краткое резюме приведенное выше.

После нескольких итераций изучения Agile по книгам, мне “повезло”, мне довелось участвовать в нескольких отечественных Agile — проектах.

От такого Agile стало совсем не весело, а РП с опытом планирования и управления проектами из телеком отрасли просто загрустил совсем. При попытках взять под контроль стихийную разработку таких молодцев, все ломается совсем, а ребята в унисон глаголят: “Мы творческие, у нас Agile, не мешайте жить/работать/развиваться”. Учиться и думать не хотят, у них только Agile в голове.

Но не смотря на мой скептический взгляд, Agile шествовал по стране, его активно продвигал Г. Греф и исповедовали разные западные и отечественные гуру ИТ-отрасли.

Но, как и показал личный опыт, Agile все используют по своему, с нашим то менталитетом мы просто создали “Agile по русски”.

Как итог, вопрос рос и креп, а ответ мне на него никто дать не мог.

Что же все таки такое этот Agile, философский стэк идей по психологии и организации труда, сумасбродства разума, и не желания работать по правилам, или за этим все же скрывается что то более серьезное с методологической точки зрения, то что можно применить и у нас на родине, на серьезных проектах, что то стоящее внимания?

Перед завершением этого раздела есть несколько моментов которые стоит отметить:

1. После выхода 6-го издания PMBoK в 2018 г. вопрос о Agile стал еще более занимательный (в 6-ом издании авторы включили кейсы с применением Agile).
2. Мне попалась для прочтения книга Лоуренса Лича, “Вовремя и в рамках бюджета”.

Книга Лоуренса Лича, “Вовремя и в рамках бюджета”

Интересная книга о проектном менеджменте по методу “Критической цепи”, автора можно отнести к идеологам тяжелого менеджмента. Книга Л. Лича описывает непростой, но крайне интересный подход по применению теорий Э. Деминга и Э.Голдратта в проектном планировании.

С учетом приобретенных теоретических и практических знаний, крепло понимание о незаконченности в понимании Agile как методологии для ее адекватной реализации в отечественных проектах.

Эндшпиль

Правильный Agile или адаптивный PMBoK от Майка Кона.

Совершенно случайно, или как говорится ”вдруг откуда не возьмись”, мне попалась очередная книга про Agile. Это книга за авторством некоего Майка Кона (Cohn Mike) под названием “Agile. Оценка и планирование проектов”.

В начале предположил, что это очередная бизнес-книга описывающая, что Agile это круто, модно, молодежно.

Так и было и решил ознакомившись с предисловием, но уже при прочтении первой главы стало интересно, кто же это такой, этот Майк Кон, и почему он пишет такие правильные вещи.

Краткая справка, кто такой Майка Кона (Cohn Mike)

Основатель Mountain Goat Software, фирмы, занимающейся консалтингом в сфере управления процессами и проектами. Он специализируется на помощи компаниям в применении agile-подхода с целью повышения эффективности. За спиной у Майка более чем 20-летний опыт работы руководителем в организациях разного размера, от стартапа до компании из списка Fortune 40. Является соучредителем организации Agile Alliance и входит в ее совет директоров.

Не планирую описывать в этой статье книгу полностью, так как лучше ее прочитать самам (тем кому нужно), но обозначу главное, книга Майка это переработанный PMBoK PMI с учетом философии Agile-манифеста.

Сразу обращу внимание, что Майк не написал очередной свод знаний, скучный и непонятный, он не копировал PMBoK. Вместо этого Майк Кон создал интересную, легко читаемую и нужную книгу:

• Описал принципы и правила, которые должны быть в Agile;
• Описал инструменты планирования и оценки работ;
• Дал представление и грамотном управлении разработкой;
• И многое другое.

В книге описан весь жизненный цикл проекта, особое внимание уделено этапу Планирования проекта, описаны очень интересные и здравые методы и подходам к планированию и оценки работ, а также описаны подходы и инструменты этапов Исполнения проекта, этапа Мониторинга и контроля.

Несмотря на то, что книга меня и так поразила по своей функциональности, применимости и методологической зрелости, так Майк еще и применил крайне интересный и сложно описанный метод по митигации рисков неопределенности, который описывает в своей книги Лоуренс Лич. При всем вышеописанном Майк предлагает простым и понятным языком как можно внедрить и расширить этот метод на практике.

Чтобы построить любой процесс, нужны правила, нормы и принципы, Майк их для нас описал.

Резюме

На мой взгляд, перед нами с 2001 г. стоят несколько интересных вопрос:

Нужна ли нам в философии Agile, методология, или нам достаточно принципов?

Хотим ли мы разрабатывать качественное ПО эффективно и понятно, или оставим эту прерогативу избранным, и продолжим “выдумывать велосипед”?

Книга Майка, на мой взгляд, определяет правила, от которых многие хотят уйти, но как показывает опыт, правила все равно нужны.

Кроме описанного выше, книга Майка дает четкие методологические указания (хотя кому-то это слово может и не нравится), о том как должно быть построено управление проектами софтверной разработки по Agile.

В любом случае, все у нас будет так, как будет, но ясно одно, правила и принципы нужны во всем, и в Agile они есть.

Эти принципы описаны и зафиксированы, их можно изучать, ими можно пользоваться.

Чтобы финализировать свое резюме, обозначу следующее:

Ageli не в кризисе, Agile не проблема, Agile работает.

Вопрос только в том, хотим ли мы изучать правила и делать как они предписывают или мы хотим продолжать работать так как хотим.

Never lose a holy curiosity.

Albert Einstein

P.S.

Уважаемые читатели, кто все же дочитал статью, мне очень интересно Ваше мнение и комментарии, а также рекомендации по аналогичным книгам, таким как книга Майка Кона.

Аджайл: что это и зачем нужно

В России распространяется Аджайл: про него говорят на заводах, в банках, страховых и бухгалтерских компаниях. Если у вас тоже намечается Аджайл, значит, самое время разобраться в теме.

Что такое Аджайл

Аджайл — это образ мышления со своей системой ценностей. Он похож на философию, религию или культуру — такой же набор установок, в которые человек верит и которые влияют на его поведение. Например, как буддизм и веганство:

Буддисты верят, что можно достичь просветления. Они медитируют, стараются быть умеренными и не причинять вреда другим.

Веганы ценят жизнь каждого живого существа. Они не используют всё, что имеет животное происхождение, и выступают против опытов на животных.

Аджайлисты верят, что работающие продукты выпускают команды самостоятельных профессионалов. Звучит как утопия, хотя Аджайл придумали программисты.

Как появился Аджайл

Раньше продукты делали сразу целиком. Для этого шли по цепочке: идея → техническое задание → дизайн → программирование → тестирование → релиз. Когда на этапе тестирования появлялась новая идея, приходилось игнорировать её или переделывать предыдущие этапы. Это было неэффективно — продукты или получались хуже, чем могли бы, или выбивались из сроков и бюджетов.

Прогрессивные разработчики стали пробовать новые подходы. Так появились Скрам, Канбан и ещё с десяток способов. Команды могли тестировать и менять продукты в процессе работы — за это такие подходы назвали гибкими. Эксперименты оказались удачными: клиенты не обманывались в ожиданиях, а разработчики укладывались в сроки и бюджеты.

Чтобы найти формулу работающих продуктов, в 2001 году 17 практиков современных подходов собрались в горной деревушке Сноубёрд. Они обсудили свои способы управления и поняли: подходы у всех разные, но идеи совпадают. Эти идеи заложили в основу Аджайла, внесли в Аджайл Манифест и дополнили Принципами Аджайла.

В чём суть философии Аджайла

И Аджайл Манифест и Принципы Аджайла описаны общими фразами, поэтому их сложно понять. Оцените сами: «люди и взаимодействия важнее процессов и инструментов» или «постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта».

Чтобы стало понятнее, сравним, как отличаются состав команд, процесс работы и результат с аджайловым образом мышления и без него. Допустим, две пекарни хотят наладить производство новой выпечки:

Аджайл — это быть командой самостоятельных профессионалов

Процесс работы тоже сильно отличается. Строгое распределение функций в традиционной пекарне и совместные эксперименты аджайловой команды:

Аджайл — это работа с клиентами и готовность изменить первоначальный план

Результат тоже разный. Непредсказуемый у одних и гарантированно хороший у других:

Аджайл — это выпуск работающих продуктов, которые нравятся всем

Идеи Аджайл Манифеста и Принципы Аджайла помогли пекарне наладить производство новой выпечки. Но крайности в идеологии вредны — неверно думать, что Аджайл отрицает регламент и планирование. Всё это есть, однако играет меньшую роль, чем живое общение людей и гибкость в работе.

Что даёт Аджайл

Аджайл меняет образ мышления, поэтому сотрудники по-новому организуют работу в компании. Появляются свобода от корпоративных формальностей, желание профессионально развиваться, чувство команды и комфортный объём нагрузки.

Свобода от начальников и бумажек. Профессионалы больше времени посвящают интересным задачам и меньше — подготовке формальных отчётов.

Отключение рядовых сотрудников от матрицы. Они перестают быть винтиками в системе и уже не ждут конца рабочего дня, чтобы начать жить. Напротив, сотрудники чувствуют, что нужны компании, и задумываются о профессиональном развитии.

Больше общения. Внутри коллектива складываются настоящие команды, где один за всех, и все за одного. Каждый делится проблемами и в нужный момент приходит на помощь ради общего успеха.

Комфортный ритм работы. Аджайл запрещает авралы и пропагандирует комфортный ритм, в котором проще справляться с новыми вызовами. Благодаря ему команды в состоянии работать бесконечно долго.

При чём тут Скрам и Канбан

Мы выяснили, что Аджайл — это философия со своей системой ценностей. Они звучат заманчиво, но использовать их в работе сложно. Не каждая команда сможет завтра работать без начальников. Не каждый клиент согласится ездить в офис разработчиков или созваниваться несколько раз в день. И непонятно, с чего начать быть аджайл.

Чтобы применить философию Аджайла на практике, используют Скрам, Канбан и другие способы управления. Это правила, которые объясняют, как организовать работу в духе Аджайла. Они бывают разной степени конкретности. Например, в Канбане шесть общих правил, а в Скраме описаны роли, события и артефакты. Их можно расширять и адаптировать, главное, следовать ценностям Аджайла.

Можно быть аджайл без правил. Так работают почти все стартапы и некоторые подразделения в корпорациях. Если вас всего двое, вы вряд ли соблюдаете регламент или строго распределяете функции между собой. Скорее вы непрерывно разгребаете кучу входящих заданий. Каждый берёт кусочек работы, который больше нравится, делает его, оглядывается на товарища. Если нужно, предлагает или принимает помощь.

Можно использовать правила без Аджайла. Так заблуждается большинство российских компаний, которые пробуют стать аджайл. Они вешают доски со стикерами, но по сути ничего не меняют. Это больше похоже на культ карго.

Что новичкам нужно знать об Аджайле

Управлять разработкой ПО почти так же сложно, как правильно выбрать технологию. Изначально программы писали последовательно, от А до Я. Эта методика хорошо работает во многих областях: от чистки зубов до решения дифференциальных уравнений. 

Но требования к ПО или мобильному приложению меняются очень быстро. Хочется добавить еще одну фичу. Или убрать, потому что вчера появилось точно такое же приложение конкурента. 

Поэтому один раз выписать все требования и выполнять их шаг за шагом, мягко говоря, неэффективно. 

Программисты, больше не в силах это терпеть, разработали подход, который позволяет добавлять изменения к проекту без вреда и нервотрепки. 

Agile, в переводе с английского — “ловкий” или “гибкий”. Он противопоставлен линейному методу — Waterfall. В отличие от него, Аджайл позволяет работать в условиях, когда не все технические рекомендации уточнены или когда они беспрерывно меняются. 

Строго говоря, Аджайл — это философия, а не набор готовых решений. Ее цель — организовать работу команды так, чтобы клиент был доволен результатом. Процесс разработки становится более клиентоориентированным. Подробнее о принципах Agile можно прочитать здесь.

Преимущества и недостатки Аджайл

Аджайл не универсален. Он может быть очень крут или наделать много бед — зависит от проекта. Посмотрим, когда его лучше использовать и где избегать.

Когда использовать Аджайл:

• Нужно снизить риски при выводе нового продукта на новый рынок. Когда технические требования к проекту быстро меняются или вы сами не знаете, куда хотите прийти, Аджайл — подходящее решение. Он создан для того, чтобы можно было вносить изменения в проект В ПРОЦЕССЕ разработки и лучше всего функционирует в условиях постоянно меняющегося рынка. 

• Чтобы сэкономить трудовые и материальные ресурсы. Сначала мы разрабатываем базовое решение, например, простой инструмент для анализа валютного рынка. Затем мы возвращаемся к его “докрутке”: добавляем новые фичи и привлекательный дизайн. Продукт функционален сразу после релиза, но такой подход позволяет избежать больших вложений на начальном этапе.

Когда Аджайл не подходит:

• Все требования к проекту ясны с самого начала. Использовать Аджайл в такой ситуации бессмысленно — если все технические требования и так ясны, нужно просто включить их в спецификацию и назначить дедлайн.
• Очень крупный и сложный проект. Делаете второй Google? Тогда забудьте про аджайл. При проектировании большого проекта нужно проанализировать огромный скоуп задач и продумать архитектуру заранее. Иначе на полпути ограничения в “железе” или другие затруднения остановят проект. И придется все переделывать.

Фреймворки

Наборы правил или рекомендаций, как следует реализовывать философию Аджайла на практике называются фреймворками. Компании, работающие по Аджайлу, выбирают тот, что лучше согласуется с их бизнес-целями. Самые популярные: Скрам (Scrum), Lean и Канбан (Kanbun). В этом посте мы расскажем про самый популярный фреймворк, который использует и Магора, — Scrum.

Введение в Scrum 

Организация Аджайл команды

Scrum-команда состоит из трех участников – владельца продукта, Scrum-команды и сертифицированного Scrum-мастера. 

Владелец продукта в Agile  — это эксперт в области развития и технологий. Он одновременно и менеджер проекта, и бренд-менеджер в традиционной бизнес-структуре. Его задача — собрать требования заказчика и организовать разработку продукта. Он — связь между клиентом и разработчиками. 

Scrum-команда создается на основе требований проекта. Обычно в ней есть дизайнеры, разработчики, бизнес-аналитики, эксперты по пользовательскому интерфейсу, тестировщики и т. д. Члены команды делятся знаниями друг с другом, проводят мозговой штурм и помогают друг другу, когда необходимо. 

Scrum-мастер — уникальная роль в методологии разработки программного обеспечения. Этот человек отвечает за интеграцию принципов Scrum в компанию. Он ведет встречи и указывает на несоответствия в следовании принципам фреймворка. В идеале Scrum-мастер следует философии «лидерства-служения».

Организация работы по Аджайл

Спринты как единица времени

В отличие от Waterfall, гибкие фреймворки делят разработку на короткие промежутки. Обычно около 2-4 недель. На каждом этапе разработки команда выполняет запланированный набор задач из беклога.

Как использовать Backlog

Бэклог (Backlog) — это список невыполненных элементов на проект, который постоянно пополняется новыми. Некоторые из них планируются при первой встрече с клиентами, в то время как другие появляются неожиданно на протяжении всего процесса разработки.

Чтобы справиться с большим списком задач и ничего не потерять, Scrum-команды часто используют доски. Это могут быть физические доски задач со стикерами или онлайн-доски Scrum. 

Доска задач Scrum разделена на три части:

— сделать;

— в процессе;

— готово. 

Стикеры с задачами перемещаются слева направо, пока все они не окажутся в последней графе.

Что такое User Story в гибкой методологии?

С первой встречи в Scrum мы создаем не список фичей, а пользовательские истории (User Stories). Это описания бизнес-целей пользователей.

Например, для инструмента мониторинга трафика цель можно сформулировать так: «Как интернет-маркетолог, я хочу видеть статистику того, сколько пользователей посетило сайт”. 

Преимущества User Story

• Отражает потребности пользователей;
• Легка для понимания;
• Может быть установлена в качестве исходной точки;
• Упрощает планирование спринта проекта.

Руководство: как создать историю пользователя.

Epic Stories

По Скраму, каждая пользовательская история должна быть завершена внутри итерации. Но иногда они слишком велики, и их невозможно покрыть за один спринт. Такие истории называются Epic Stories (эпическими историями) или epics. 

Для завершения итерации они должны быть разделены на более мелкие пользовательские истории. Чтобы оценить сложность истории пользователя, используют бальную систему. 

Диаграмма сгорания задач

Диаграмма сгорания задач, или в английском варианте Burndown chart, используется во время более длительных итераций, чтобы увидеть, сможет ли команда завершить все заявленные User Stories. 

Каждый график имеет две линии. Одна показывает желаемый результат, а вторая — суровые факты. Узнайте, как нарисовать диаграмму здесь.

События в Scrum 

В Scrum есть 4 официальных «события» — митинги, которые должны проводиться регулярно. Здесь и заключается основное различие между Скрамом и любыми другими фреймворками — если лень проводить митинги, это уже не Скрам.

Sprint Planning Meeting

Этот митинг — отправная точка спринта, когда планируется вся итерация. Владелец продукта устанавливает цели спринта и вместе с командой выбирает пользовательские истории из бэклога для реализации. 

На совещании по планированию команда решает, как реализовать выбранные User Stories. Участники оценивают сложность задач и сколько часов это займет. При этом соответствующая информация о каждой пользовательской истории размещается на Scrum-доске.

Ежедневные стендапы

Согласно рекомендациям Scrum, ежедневные стендапы должны проводиться для команды. Так каждый член в курсе, какой точки достигли их товарищи по команде. Всем задают эти 3 вопроса: 

• Что ты сделал вчера?
• Что ты планируешь делать сегодня?
• Существуют ли какие-либо препятствия?

Ежедневные встречи проводятся Scrum-мастером. Они не должны превышать 15 минут. Если есть какие-либо серьезные нерешенные вопросы, члены команды обсуждают их позже.

Sprint Review 

В конце каждого спринта команда проводит обзорную встречу. Команда показывает, что было сделано владельцу продукта. Клиент также может принять участие во встрече. Владелец продукта проверяет, соответствует ли проект критериям приемки и, если все в порядке, все задачи помечаются как выполненные.

Retrospective Meeting

Это заключительное собрание итерации, где команда встречается, обсуждает и документирует следующее:

1. Что прошло хорошо во время спринта?
2. Что можно было сделать лучше?
3. Усвоенные уроки
4. Точки роста.

Команда должна стремиться внедрять передовой опыт и учиться на своих ошибках в следующий раз.

На этом все. Теперь вы знаете, что такое Аджайл и сможете отличить Скрам-мастера от простого менеджера. Если вы пока не уверены, что стоит включить в ваш проект, то Скрам — это то, что нужно. 

Lean + Agile / Habr

Гибридная методология управления на основе ценностей

В этой статье мы расскажем вам об Agilean («Эджайлин») как методе создания гибридных инструментов на базе Lean и Agile и шире об Agilean как о философии управления бизнесом с плацдарма ценностей.

Немного поговорим о нюансах физиологии и психологии человека, исходя из которых была сформулирована логика метода Agilean, и, в заключении, разберем практический пример и принципы применения этого гибридного метода для решения бизнес-задач.

Счастье в труде или понимание дофаминовой основы мотивации сотрудников

Рассматривая биологические системы и механизмы, созданные Природой (можете подставить сюда «Бог», «Высшие силы» или любое другое слово, которое вам больше нравится), нельзя не восхищаться тем, насколько сложны и в то же время гармоничны и надёжны, инженерные решения, применённые в строительстве человеческого организма. Многим из них миллионы лет, но они остаются неизменными и продолжают успешно выполнять свои функции, несмотря на радикально изменившиеся условия применения.

Вечная актуальность и эффективность этих решений обеспечивается тем, что они строятся не на контекстных условиях, а на базовых принципах. Разберём одно их них, а именно механизм «непрерывного улучшения» и стремления к постоянному развитию. Своеобразный физио-психологический kaizen человека.

При создании эффективного организма перед природой лежала задача, как сделать так, чтобы каждая особь популяции непрерывно стремилась не только к размножению и укреплению своей безопасности, но и к непрерывному развитию и улучшению всех аспектов существования популяции.

Как и с другими основными инстинктами, Природа решила эту задачу при помощи связки «рептильный мозг» человека + гормональная система.

При «социально-неправильном» поведении человека рептильный мозг отдаёт команду гормональной системе применить «кнут» в виде выделения гормона депрессии и саморазрушения – кортизола, и «пряник» — в виде выделения гормона мотивации и предвкушения счастья – дофамина при «социально-правильном» поведении.

Решение того, как понимать, какое социальное поведение человека правильное (направленное на развитие популяции) и какое неправильное (направленное на что угодно кроме развития популяции), тоже было простым, надёжным и элегантным, как всё, что делает Природа.

Наш туповатый «рептильный» мозг просто считывает, что думают о нашем поведении окружающие нас люди, используя наши мысли на этот счёт. Если мы считываем реакцию социума на наши действия как одобряющую, то древний мозг открывает дофаминовые краники, наполняющие нас радостью, предвкушением награды, а также энергией и неутомимой волей к преодолению преград по дороге к цели.

Вспомните момент, когда вы взялись за важный проект, результаты, которого, как вы точно знали, могли сильно продвинуть вас и упрочить ваше карьерное положение, и с каждым успешным шагом ваш мозг затоплял вас радостным предвкушением. Вам хотелось думать только о проекте и о его целях, вы могли без устали работать по 20 часов в день, и просыпались наполненными кипучей позитивной энергией, несмотря на недосып и нездоровый режим питания.

Но вам наверняка не составит труда вспомнить и те моменты, когда успех проекта был под угрозой – стресс, беспокойство и страх, если риски неудачи были не фатальны. А при полном провале, когда вы понимали, что успех проекта практически недостижим, вы ощущали депрессию, апатию, невозможность заставить себя сделать хоть что-либо и стойкое желание «бросить всё и уехать в Гагры».

Кортизол и дофамин — проделки старой доброй матушки Природы, которая без тени сомнения готова подвергнуть нас любым страданиям, если мы не приносим пользу популяции, но не откажет и в награде, если мы полезны.

Именно поэтому человек, оказывающийся в бездействии неминуемо тяготеет к искусственной генерации дофамина в виде таких быстрых удовольствий, как наркотики, алкоголь, обжорство и т.д.

— Это всё занимательная информация, — скажете вы. – Но причём здесь Lean, Agile и управление бизнесом?

Ок. Давайте рассмотрим причём здесь управление бизнесом и какой практический смысл для нас, людей дела, имеет вся эта информация.

Theory of Constraints для механизмов и людей

В далёких 80х Элияху Голдрат разработал «Теорию ограничений». Как гласит Википедия «Основной особенностью его методологии является то, что делая усилия над управлением очень малым количеством аспектов системы, достигается эффект, намного превышающий результат одновременного воздействия на все или большинство проблемных областей системы сразу или поочерёдно.

Подход теории ограничений основан на том, чтобы выявлять это ограничение и управлять им для увеличения эффективности достижения поставленной цели (для бизнеса ускорение и увеличение генерации прибыли). Где эффективность – это скорость достижения цели с минимально возможными затратами и без урезания цели по содержанию.»

Несмотря на то, что Теория ограничений постепенно эволюционировала как методология по решению любых системных проблемы малыми затратами, основное применение она получила в области оптимизации производственных процессов. По сути, все её действия направлены на повышение двух основных KPI работы оборудования — КИО (коэффициент использования оборудования) и КТГ (коэффициент технической готовности).

Если использовать её принципы совсем примитивно, то для создания максимально эффективной производственной цепочки вы должны устранить узкие места («бутылочные горлышки») процесса, настроить работу всех единиц оборудования в одном ритме и поддерживать техническое состояние каждой единицы оборудования в оптимальном для механизма состоянии – работе на полную проектную мощность с минимальным количеством сбоев.

В соответствии с принципами гибридного подхода Agilean, мы взяли эту методологию и применили к людям, однако при этом учитывая, что люди – не механизмы, и обеспечение максимального КИО (коэффициент использования оборудования) и КТГ (коэффициент технической готовности) для людей достигается другими методами.

После нехитрых рассуждений мы приходим к выводу, что для построения идеальных организационных процессов (в отличие от производственных) мы должны обеспечить 1) максимальную расшивку процесса коммуникации (потому что в отличие от механизмов, люди в организационном процессе приводят друг друга в движение при помощи коммуникации, а не шкивов и шестерней), 2) механизм постоянной мотивации, который будет заставлять каждую единицу человеческой цепи работать на своей максимальной проектной мощности при минимальной амортизации.

И если ценность свободной коммуникации как обеспечения быстродействия человеческих цепей (организаций) довольно известна и очевидна просвещённому кругу бизнес-деятелей, то ценность самоорганизации как единственного идеального инструмента вовлечения и мотивации сотрудников не для всех очевидна.

Более того (автор позволит себе небольшое лирическое отступление по этому наболевшему вопросу) HR-службы практически всех крупных современных российских компаний с упорством достойным лучшего применения продолжают наполнять свои корпоративные программы повышения вовлечённости сотрудников такими вещами, как «улучшение бытовых условий сотрудников», «путёвки для лучших сотрудников» и т.д. и т.п, каждый раз удивляясь, почему же результаты такой мотивации дают лишь кратковременный эффект.

Если бы они понимали принципы дофаминовой мотивации, им бы быстро стало очевидно, что их программы вовлечённости похожи на пичканье бездельника наркотиками – эффект кратковременный и с каждым разом всё более малоощутимый, а синдром отмены разрушительный.

Какие же принципы дофаминовой мотивации нужно знать, чтобы сделать вовлечённость ваших сотрудников максимально высокой, незатратной для компании, постоянной и самовозобновляемой.

Принципы эти просты:

• «Амбициозные, но достижимые цели» — «рептильный мозг» выдаст сотруднику много дофаминовой энергии-мотивации, только если он сам считает, что цель важна. Но также цель должна быть достижимой, потому что страх «кортизольного» кнута не позволит ему действовать в случае высокой вероятности провала.
• «Самоорганизация» — «рептильный мозг» откроет дофаминовые краники только в случае если поставленная задача будет подчёркивать высокую ценность человека в глазах популяции — сравните постановку задачи руководителем: «Эдуард, компания решила запустить важный для компании проект, и мы считаем, что только вы можете привести его к успеху, подумайте и предложите наилучший вариант его реализации» и «Эдуард, проект очень важный, так что я написал вот тут детальный план, где расчертил всё до мелочей, следуйте ему неукоснительно и отчитывайтесь о продвижении каждый день утром и вечером».

Очевидно, что в первом случае рептильный мозг считает высокую важность человека для популяции и затопит его дофаминовой мотивацией, а во втором, безошибочно поймёт, что важен для популяции как раз руководитель, а Эдуард лишь тупой инструмент, способный только на выполнение чьих-то инструкций. Собственно и вместо энергии во втором случае Эдуард получит кортизольную дубину, от которой любая мысль о выполнении такого задания вызовет опущенные руки, стойкую зевоту и желание выполнить его максимально формально, а лучше вообще от него уклониться.

Зная эти принципы психо-физиологического механизма мотивации человека и трансформировав их в определённый набор культурных ценностей, мы можем выстраивать идеальный организационный формат любой бизнес-деятельности, точечно выбирая, адаптируя и гибридизируя инструменты из любых бизнес методологий.

То есть применяя и гибридизируя Теорию ограничений Голдратта к человеческому взаимодействию мы можем вывести следующие коэффициенты – КИЭ (коэффициент использования энергии) и КЭГ (коэффициент энергетической готовности). Также с учётом этих принципов легко сформулировать культурные ценности, создающие условия для повышения этих коэффициентов и привести примеры инструментов из разных бизнес методологий, которые мы можем для этого использовать.

Agilean на практике – бизнес-кейс компании “X”

Теперь, когда основные принципы Agilean-философии изложены, мы приведем пример их практического применения, для того, чтобы было ясно, как метод гибридной разработки инструментов на базе этой философии может приносить реальную ценность бизнесу.

Бизнес-результаты трансформации:

• Финансовые показатели, поставленные клиентом как целевые на весь срок реализации (8 месяцев), достигнуты за первый месяц внедрения.
• Выполнены и перевыполнены все операционные KPI, поставленные на отчётный период
• В рамках проекта сгенерированы решения по операционным улучшениям в несколько десятков раз превышающие изначальные целевые финансовые показатели и сходные показатели по нескольким аналогичным проектам, внедряемым на других бизнес-единицах по классическим Lean-методологиям
• Повышена мораль и вовлечённость коллектива
• Успешная культурная трансформация зафиксирована в рамках пилотного проекта

«И одно кольцо, чтобы править всеми…»

На примере данного бизнес-кейса продемонстрированы преимущества методологии Agilean над классическими методологиями и философиями оптимизации бизнеса типа Lean, Agile, ToC и всех подобных существующих на сегодняшний день. Они заключаются в следующем:

• Нет необходимости «внедрения методологии и философии», не надо заучивать нюансы и тонкости применения методологий, которые разрабатывались в другом контексте, возможно отличном от вашего
• Легко диагностировать проблемы и предложить улучшения только на основании только диагностики состояния основных ценностей
• Вы можете создавать новые, изменять и гибридизировать существующие инструменты, отталкиваясь от конкретного случая, конкретных проблем и контекста на базе понимания ценностей и общей бизнес логики
• Быстрое внедрение, быстрые и ощутимые улучшения

По сути основанный на понимании психофизиологических процессов мотивации человека метод Agilean – это шаг на следующую ступень разработки и понимания методологий по повышению эффективности бизнеса. Он представляет набор принципов, объединяющий все существующие методологии, может объединять и использовать любые инструменты повышения эффективности и раскрывает простые принципы выбора или создания инструментов под конкретную проблему.

что это и зачем нужно

В России распространяется Аджайл: про него говорят в страховых и бухгалтерский компаниях, в банках и на заводах. Если в вашей компании тоже скоро будет Аджайл, самое время разобраться в теме.

Что такое Аджайл

Аджайл — это образ мышления со своей системой ценностей. Он похож на философию, религию и культуру — это тоже наборы установок, в которые человек верит и которые влияют на его поведение. Как буддизм или веганство:

Буддисты верят, что могут достичь просветления. Они медитируют, стараются быть умеренными и не причиняют вреда другим.

Веганы ценят жизнь каждого живого существа и заботятся об экологии планеты. Они не используют все, что имеет животное происхождение и выступают против опытов на животных.

Аджайлисты верят, что идеальные продукты создают команды самостоятельных профессионалов. Звучит как утопия, хотя Аджайл придумали практичные программисты.

Как появился Аджайл

Раньше продукты делали сразу целиком. Для этого они шли по цепочке: «идея → техзадание → дизайн → программирование → тестирование → релиз». Если на этапе дизайна появлялась новая идея, приходилось игнорировать ее или переделывать все предыдущие этапы. Это было неудобно — проект или получался хуже, чем мог бы, или растягивался во времени и не укладывался в бюджет.

Прогрессивные разработчики стали пробовать новые подходы к работе. Так появились экстремальное программирование, Скрам и ещё с десяток новых техник. Команды могли тестировать и изменять продукт в процессе работы, за это такие подходы назвали «гибкими». Эксперименты оказались удачными: клиенты получали отличные продукты, разработчики выдерживали сроки и бюджеты, а размеры компании не влияли на продуктивность команды.

Чтобы найти формулу успешных продуктов, в 2001 году семнадцать практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои стратегии разработки и сделали открытие: подходы у всех разные, но общие идеи совпадают. Эти идеи легли в основу «гибкой» философии, которую назвали Аджайлом. Их записали в итоговых документах: «Манифесте» и «Принципах Аджайла».

В чем суть философии Аджайла

И «Манифест», и «Принципы Аджайла» написаны очень общими фразами, поэтому их трудно понять. Оцените сами: «люди и взаимодействия важнее процессов и инструментов», «самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд» или «постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта».

Чтобы стало понятно, сравним как отличаются составы команд, процесс работы и результат у команды с аджайл образом мышления и без него. Допустим, две условные пекарни хотят наладить производство и продажу новых пирожных.

Аджайл — это быть командой профессионалов, которым не нужен начальник

Процесс работы тоже отличается: строгое распределение функций в традиционной пекарне и совместные эксперименты аджайл-команды:

Аджайл — это работа вместе с клиентом, эксперименты и готовность изменить план

Результаты пекарен будут кардинально различаться: непредсказуемые у одних и гарантированно хорошие у других:

Аджайл — это быстрый выпуск работающего продукта, который нравится клиентам и заказчикам

Чтобы выстроить работу в духе аджайла пекарня из нашего примера использовала в работе постулаты «Манифеста»:

• люди и взаимодействия важнее процессов и инструментов,
• работающий продукт важнее исчерпывающей документации,
• сотрудничество с заказчиком важнее согласования условий контракта,
• готовность к изменениям важнее следования первоначальному плану.

Аджайл образ мышления помогает компаниям становиться успешными. Но в вопросах идеологии любые крайности вредны — неверно думать, что аджайл отрицает регламенты, документацию, договоры и планирование. Все это есть, но оно имеет гораздо меньшую роль, чем живое взаимодействие людей и гибкость в работе.

Что дает Аджайл

Аджайл меняет мышление, поэтому сотрудники пробуют новые роли, перестраивают бизнес-процессы и по-другому организуют работу в компании. Аджайл приносит свободу от формальностей корпорации, желание профессионально развиваться, чувство команды и комфортный ритм работы.

Свобода от диктата бумажек и начальников. Профессионалы могут больше времени посвящать интересным задачам и развитию своего потенциала, и меньше — подготовке формальных отчетов или бессмысленным митингам ради регламента.

Отключение от матрицы рядовых сотрудников. Они перестают быть винтиками, от которых ничего не зависит. Люди задумываются о профессиональном развитии, работа становится важной и интересной. Сотрудники перестают ждать окончания рабочего дня, чтобы выйти из офиса и начать жить.

Больше общения. Внутри коллектива складываются настоящие команды, где «один за всех, и все за одного». Такие мушкетеры делятся проблемами и в нужный момент приходят товарищу на помощь ради успеха общего дела.

Комфортный режим работы и объем нагрузки. Один из принципов Аджайла: команда должна быть в состоянии работать бесконечно долго. Аджайл запрещает авралы и пропагандирует комфортный ритм, в котором интересно работать и справляться с новыми профессиональными вызовами.

Аджайл помогает быть счастливее: видеть в работе дело жизни и получать от нее удовольствие.

При чем здесь Скрам и Канбан

Мы выяснили, что Аджайл — это набор философских ценностей. Они звучат заманчиво, но использовать их в жизни сложно. Не каждая команда может завтра начать работать без начальника. Непонятно, как делать проект без подробного ТЗ. Не всякий клиент согласится ездить в офис разработчиков каждый день или созваниваться по нескольку раз в день. И с чего начать быть аджайл не понятно.

Чтобы применить философию на практике используют фреймворки: Скрам, Канбан, экстремальное программирование, бережливая разработка и другие.

Фреймворк — это набор готовых правил, которые показывают, как организовать рабочий процесс по принципам Аджайла. Они бывают разной степени конкретности. Например, в Канбане шесть общих правил, а в Скраме описаны роли, встречи и артефакты. Наборы правил можно расширять и адаптировать, главное — следовать постулатам и принципам Аджайла.

Можно быть аджайл без фреймворков. Так работают почти все стартапы и некоторые подразделения в крупных компаниях. Если вас в отделе всего двое, вряд ли вы сосредоточены на соблюдении регламентов или четко распределяете функции между собой. Скорее вы напару непрерывно разгребаете огромную кучу входящих заданий. Каждый берет кусок работы, который больше нравится, делает его, оглядывается на напарника. Если надо — помогает или принимает помощь.

Сами того не зная, вы разделяете философию Аджайла, хотя и не используете фреймворки.

Можно использовать фреймворки без Аджайла. Это беда большинства российских компаний, которые пробуют Аджайл. Часто они вешают доски с листочками-задачами, переименовывают планерки в митинги, но по сути ничего не меняют. Это малоэффективно и похоже на культ Карго.

Лучший вариант — соединить философию с практикой и получить предсказуемо хороший результат.

Шпаргалка

agilebasics.ru

SAFe или Scaled Agile Framework / Habr

Что такое SAFe?

Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Одним из важных преимуществ и недостатков SCRUM-а я считаю предписываемый размер команд — 7+-2 (или 3-9 более свежие данные из Scrum Guide) включая Product Owner.

Безусловно 9 высококлассных и хорошо замотивированных профессионала способны на многое, но иногда бывает необходимость все-таки построить что-то большим количеством рук, голов, глаз и мозгов в конце-концов. Раздувать команды — плохо, значит их количество надо наращивать, а тут возникает проблема коммуникации между командами, синхронизация работы и сам по себе SCRUM никакого решения для этих задач не предлагает. Есть попытки использовать SCRUM на уровне управления SCRUM командами (так советует делать Jeff Sutherland — один из авторов Agile manifesto), есть Large Scale Scrum, есть Disciplined Agile Delivery, есть много еще что, но еще есть SAFe — Scaled Agile Framework.

SAFe — это фреймворк для управления компанией в которой требуется координация работы над некоторым проектом или связанными проектами для 5 или более SCRUM командами. Т.е. это некая надстройка над SCRUM позволяющая управлять коллективами из 100 и более человек

Выгода?

В первую очередь, разумеется методология нужна тем, кто ее продает и занимается тренингами. На эту тему неплохо высказался Dave Thomas (еще один из авторов Agile manifesto) На GOTO 2015 в своей презентации Agile is Dead

Во-вторую очередь отделы управления программами. Те, кто раньше занимался управлением проектами, получали PMP сертификации, рисовали диаграммы Гантта и реализовывали концепцию твердо-мягкого управления (мягкой стороной к руководству и твердой к исполнителям). Дело в том, что в типичном SCRUM для них нет функции, в SAFe — есть. То же самое относится к разного рода архитекторам. В SCRUM для них нет функции в SAFe — есть карьерный путь.

Далее — это может быть выгодно тем владельцам бизнеса, где управляющие работают над большими, пожирающими огромное количество человеко-часов проектами и не могут (иногда по объективным причинам) сделать эти проекты независимыми.

Множеству разработчиков с квалификацией ниже среднего, т.к. часто для того, чтобы что-то сделать их нужно экспоненциально больше чем тех самых опытных и замотивированных профессионалов.

В целом индустрии. Т.к. количество разработчиков удваивается каждые 5 лет (см. uncle bob’s future of programming), следствием чего является то, что в каждый момент времени по крайней мере половина разработчиков обладают опытом работы менее 5 лет. Если тенденция не изменится, а судя по всему — не изменится, значит требуется процессы предписывающие и формализующие их рабочие функции, механизмы взаимодействия мужду участниками и в целом процессы.

Суть

SAFe — это слоеный пирог из различных методик Agile. На нижнем уровне находится практически традиционный SCRUM, с типичными двух-трех недельными спринтами, командами по 3-9 человек включая Product Owner. Все типичные ритуалы, начиная от ежедневной планерки — standup и заканчивая разбором полетов на restrospective. Хотя есть одно ключевое отличие. Команда перестает быть полнофункциональным независимым модулем. И спринт перестает быть независимым отрезком времени с полным жизненным циклом. Спринты объединяются в Program Increments состоящие из обычно 5 спринтов. Т.е. если в классическом SCRUM мы построили не то, что клиенту нравится — то мы производим коррекцию курса в следующем спринте, то в SAFe мы продолжаем идти в сторону обрыва до конца Program Increment в худшем случае следующие 4 спринта (разумеется я утрирую).

На следующем уровне у нас поезда — так называемые Agile Release Train. Для управления 5 спринтовыми отрезками появляются новые функции — системный архитектор (тот, кто владеет архитектурой — т.е. это больше не команда), product manager (тот кто управляет продуктом, а не Product Owner, последний ходит за советом к PM) и RTE — тот самый PMP из далекого мира waterfall. Здесь применяются некоторые наработки из Kanban в частности доска, способ назначения приоритетов и в целом остается принцип измерения исторической производительности команд (velocity) и проецирование того, что будет построено в конце временного отрезка в противовес подходу с оценками и назначением сроков выполнения для уже зафиксированного функционала (scope). Одним из нововведений становится то, что последний спринт из 5 объявляется организационным и во время него проводятся огромные собрания (все команды вместе — а это 100 и более человек), проводится анализ технического долга, строятся планы по проработке архитектуры и синхронизируется работа всех команд.

Над уровнем поездов у нас координация между отделами, директорами, и клиентом. Тут больше идет заимствование из Lean Agile, но сохраняются те же инструменты из Kanban. Здесь проводится анализ экономической целесообразности изменений. В идеале любые изменения проходят через предварительный анализ где выдвигается измеримая гипотеза о предстоящем изменении (например если мы произведем онлайн магазина из датацентра в облако, то быстро наращивая мощности в пик сезонных распродаж сможем увеличить количество сделок на 10%) и далее эта гипотеза либо подтверждается либо нет. Для компаний менее миллиарда долларов — это может быть самый последний этаж. Здесь же создаются планы работ на 12-36 месяцев (привет пятилетки качества, количества и т.д.)

Над уровнем больших систем идет управление портфолио. Распределяются средства на различные направления в бизнесе. Используется lean portfolio management, используя стратегию развития компании выбираются направления от которых можно получить отдачу. Здесь принимаются решения о покупке или слиянии с другими компаниями. Создание новых направлений бизнеса, закрытие старых. Регулярно проводится корректировка и прере назначение бюджета (в противовес квартальными или годовым планам). Для каждого компонента портфолио устанавливается набор более-менее стандартизированных метрик и далее все оцениваются по ним. Так же как и на 3 предыдущих уровнях есть специальные ритуалы для синхронизации каждые две недели (обычно) — происходит обмен статусами и ключевыми индикаторами.

Во-главе всего стратегия. То, как она определяется — фреймворк не описывает.

Плюсы

1. Значительно количество весьма неплохих инструментов (WSJF, Kanban, Gemba, etc)
2. Формализируются и прописываются шаги для SDLC начиная от написания кода (предписывается TDD) заканчивая выполнения статического сканирования и CI/CD и feature toggle. Хороша каждая из практик или нет — другой вопрос, но по крайней мере есть план и все ему следуют.
3. Процесс можно понять, объяснить и внедрить.
4. Каждый человек в рамках этого процесса, получает достаточно строго определенную функцию.
5. Повышается прозрачность компании для тех, кто в ней работает.

Недостатки

1. Достаточно длительное время реагирование на несоответствие реальности ожиданиям
2. Огромное количество средств и денег тратится на коммуникацию и собрания
3. Часто рекомендуемые решения в рамках фреймворка уже устарели

Внедрять или нет? Я считаю, что если есть выбор — то нет, лучше снижать зависимость между отделами и проектами. А если выбора нет и нужно управлять огромным проектом, то вполне можно.