В принципе, agile-процесс — это отличный инструмент для стартапов, но не для крупных компаний с большим количеством процессов, которые действуют уже долгое время. Здесь более эффективны масштабируемые элементы Agile, такие как SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Что такое Agile-подход в бизнесе
Об Agile еще не писал только ленивый, сейчас самое время. 🙂 В русскоязычных источниках agile-методологию часто называют agile-методологией организации команд разработчиков. В этом есть большая доля правды: agile-разработка возникла как набор различных подходов к разработке программного обеспечения. Но как философия она уже давно перекочевала в бизнес. Мы объясним, что такое Agile и как вы можете использовать его для управления проектами в своей компании.
Коллеги, извините меня.
Сразу хотим предупредить: это не Википедия, а уютное луркоморье. Мы не претендуем на абсолютную истину, но мы приводим детали из нашего опыта и пытаемся показать новичкам подход, о котором говорит каждая газета. Если вы с чем-то не согласны и некоторые моменты в статье вызывают у вас щекотку ниже пояса, читайте остальные наши материалы.
Главное, что нужно знать про Agile
Гибкость — это не методология, это система ценностей. Да, мы все читали о agile-разработке программного обеспечения как о методологии разработки программного обеспечения здесь, в Oko. Мы также читали о манифесте agile. И вот мы пришли к выводу, что на самом деле это не конкретная методология, а некий собирательный образ. Мы с командой решили, что Advjail — это сочетание подходов и методов управления, система ценностей, которая:
- фокусирует команду на потребностях клиента
- упрощает организационную структуру и процессы компании
- итерации командной работы — короткие, повторяющиеся циклы работы
- корректирует результаты на основе отзывов клиентов/заказчиков
- расширяет возможности членов команды
- использует гуманистический подход и мотивирует членов команды
- Скорее образ жизни, чем метод управления
Вы можете сказать: — Какая разница, все эти принципы работают и в нашей компании. Ну и что, что это большое дело, все это большое дело…».
И вы были бы правы! В Oko мы решили не переоценивать роль аджайла, а просто применять эти принципы в работе команды. Более подробно мы проанализируем эти значения позже. Наш итеративный подход позволил нам ускорить создание ценности для наших клиентов и избежать ненужной головной боли.
Работа Аджайлы — это работа короткими итерациями. Мы ввели в работу команды короткие итерации продолжительностью 2-3 недели. В конце каждой итерации команда создает мини-продукт или отдельную часть общего продукта, который затем может быть выпущен как самостоятельный продукт. Мы тестируем, анализируем результаты и решаем, что правильно, что неправильно и что является приоритетным для следующей итерации. Другими словами: Мы работаем над продуктом, используя гибкий подход. Мы меняем стратегию и продолжаем работать в том же духе.
В компании Ajail все члены команды равны. Нет четкой иерархии. Разработчик, менеджер и редактор, дизайнер и тестировщик имеют абсолютно равные полномочия. Все сосредоточены на своей работе. Если кто-то ошибается, работа всей команды разваливается — это не мотивация. Кроме того, у команды есть владелец продукта, который фокусируется на выгоде для клиента и решает, какие изменения следует внедрить в первую очередь.
Adjail необходим для того, чтобы быстрее вывести продукт на рынок. Таким образом, мы улучшаем продукт, повышаем качество обслуживания клиентов, снижаем неэффективность — и рационально распределяем время и ресурсы команды. Это работает в условиях неопределенности.
Например, когда мы начинали работать с OkoCRM, приоритет был отдан модулям управления бизнесом и задачами. Мы чувствовали, что это самое важное для наших клиентов. Когда мы выпустили первую версию и собрали отзывы клиентов, мы поняли, что люди заинтересованы в модуле управления проектами. Мы изменили наши приоритеты, и первое, с чем мы вышли, был только модуль управления проектами.
В компании Ajail клиент стоит на первом месте. Они должны любить продукт и решать поставленные перед ними задачи. Поэтому вся наша работа основана на том, чтобы выяснить, что нужно конечному пользователю в первую очередь. Команда дорабатывает новую функциональность к концу итерации, развертывает ее и сразу же собирает отзывы — так мы можем определить приоритеты новой итерации. Таким образом, у нас больше шансов получить продукт, за который люди готовы платить.
Agile включает в себя две методологии: Scrum и Kanban. Первый включает в себя итерации по времени — спринты, в ходе которых команда выполняет определенный объем высокоприоритетной работы до тех пор, пока ресурсы спринта не будут исчерпаны. Вторая сосредоточена на том, чтобы сделать как можно больше работы и постоянно выпускать новые версии. Кстати, мы построили модуль сделок и воронку продаж в OkoCRM по принципу таблицы Канбан.
Почему Agile — не методология
В кругах разработчиков преобладает мнение, что agile development — это методология разработки. Но это не так! Люди характеризуют agile-разработку таким образом по аналогии с другими методологиями и подходами к разработке программного обеспечения — RAD, RUP, XP и другими. Однако существуют некоторые фундаментальные различия.
Jail состоит из 4 основных ценностей и 12 основных принципов. Вот и все. Тогда как, например, те же RUP и XP — это десятки страниц технической документации, конкретные методики, правила, инструменты и алгоритмы. Если эти правила нарушаются, методология ломается, и любая гибкость исключается. Для многих из этих методологий были предприняты попытки упростить и сократить их. OpenUP, например, более гибок и прост по сравнению с RUP, но до гибкости ему еще далеко.
С другой стороны, Scrum — это методология. Существует четкое распределение ролей в команде, определенный набор действий и алгоритмов, нарушение которых разрушает работоспособность команды. Но agile-методологии не имеют конкретных процессов, элементов и правил. Существуют всеобъемлющие ценности и общие принципы.
В agile нет определенных процессов, алгоритмов или жестких правил. Есть только ценности и принципы. Таким образом, гибкость — это не методология.
У маневренности есть свои преимущества и недостатки. Некоторые из них покажутся вам пустяком. А некоторые из них могут вызвать хаос в офисе и заблокировать работу команды на неделю. Чтобы помочь вам сразу оценить риски его принятия, мы составили список плюсов и минусов agile-разработки, основанный на нашем опыте. Итак.
Чем Agile отличается от методологий
Термин «методология» используется для agile-разработки по аналогии с более ранними подходами к организации разработки программного обеспечения: RAD, RUP, XP и другие.
Однако те, кто сталкивался с agile-подходом, знают, что он не сравним с более ранними подходами, которые подробно описывали процесс разработки. Agile — это коротко: он состоит из 4 ценностей и 12 принципов. А описание методологии RUP, например, занимает десятки страниц — речь идет о множестве приемов и алгоритмов действий. RUP (Rational Unified Process) включает в себя разделение жизненного цикла разработки на 4 фазы, рекомендуемые соотношения нагрузки в 9 рабочих процессах в каждой фазе и специфические инструменты для каждого потока. OpenUP, самая последняя методология-преемник RUP, короче и гибче, но все еще далека от краткости Agile.
Методология — это совокупность методов и приемов, используемых в различных областях деятельности.
Методология — это способ достижения цели.
Сам по себе Agile не дает алгоритмов, методов и техник. Однако «гибкие» подходы, включенные в agile-подход, часто предписывают определенные техники:
- Метод agile XP (Extreme Programming), например, включает такие техники, как парное программирование и игровое программирование, которые предписывают вполне конкретные алгоритмы действий.
- И даже agile Scrum framework, который по определению является «не процессом, не техникой и не методом», предусматривает реализацию различных ролей, действий и объектов. Каждый элемент Scrum является обязательным для успешного применения.
В отличие от методов, техник и рамок разработки программного обеспечения, Agile основан не на конкретных процессах или даже элементах процесса, а на всеобъемлющих ценностях.
Соблюдение этих ценностей повышает скорость разработки и бизнес-ценность разрабатываемых продуктов. В то же время, затраты на разработку могут увеличиться, поэтому гибкость не всегда необходима. Более подробную информацию см. в разделе «Сфера применения Agile».
Приведенная выше условная схема Agile-подходов взята из книги Бориса Вольфсона «Методологии Agile-разработки». Это краткое руководство по широкому спектру инструментов управления agile достаточно хорошо для своего времени (2012 год), когда agile применялся только в той отрасли, из которой он пришел — разработке программного обеспечения. Однако, если вы не работаете в этой отрасли, вам следует читать более современные книги без знания ИТ, чтобы узнать больше.
Таким образом, agile — это не методология разработки, а система ценностей, которая помогает разработчикам создавать новые продукты быстрее и с большим влиянием на бизнес:
- За счет более эффективного взаимодействия с клиентами и друг с другом, не ограниченного жестким контрактом или негибким внутренним процессом,
- быстро реагировать на изменения, причем с обеих сторон,
- Фокусировка на функциональном продукте, а не на вспомогательных вещах, таких как документация.
Эти ценности настолько общие и абстрактные, что гибкость часто называют философией.
Существует также термин «Agile Mindset», который означает, что человек понимает ценности Agile.
Изменение мышления менеджеров и руководителей с традиционного на Agile — самая сложная задача при внедрении Agile-подхода в команде или компании.
Сегодня Agile-мышление чаще всего используется в контексте Scrum, поэтому неудивительно, что эти два термина очень часто используются вместе.
- Если agile мышление не внедрено в людей, Scrum просто приведет к более дорогостоящему развитию, потому что больше времени нужно тратить на коммуникацию и обратную связь, требуются новые роли, ресурсы на обучение, смена персонала и т.д.
- И наоборот: без конкретного подхода (например, Scrum) Agile останется просто красивой философией — абстракцией, которую большинство людей не могут превратить в руководство для повседневной работы.
По этой причине Agile и Scrum обычно изучают вместе. На нашем сайте вы найдете десятки статей по agile-менеджменту в разделе Agile и Scrum.
Исторически сложилось так, что Agile также включает Kanban, поэтому самая универсальная международная сертификация по Agile, ICAgile Certified Professional, включает не только Scrum, но и Kanban.
Agile сложнее, чем 4 ценности
Во-первых, помимо ценностей, в Манифесте Agile есть еще 12 принципов, которые уточняют и дополняют ценности.
Во-вторых, в статье «Что такое agile working и зачем он нужен компаниям» вы найдете подробное описание 6 характеристик agile working, которые гораздо более конкретны, чем ценности или даже принципы. Я кратко изложу их здесь:
- Потребности клиентов понятны всем. Важно, что в agile-подходе не только компания и менеджер продукта, но и вся команда ориентируется на потребности клиента. Это означает, что каждый из разработчиков знает, кто является потребителем, что ему нужно и какие проблемы будет решать новый продукт. Это помогает найти более подходящие решения.
- Процессы и организационные структуры максимально упрощены. Правила и процессы, используемые в agile-командах, должны быть простыми, чтобы люди могли сосредоточиться на клиенте и продукте, который они создают.
- Работайте короткими циклами (итерациями). Цикл длится около недели или месяца, в течение которых разработчики производят полезную продукцию для заказчика.
- Систематическая обратная связь. Разработчики демонстрируют продукт клиенту, получают отзывы о продукте и информацию об изменениях в проектах клиента, затем улучшают его, добавляют что-то полезное и так далее по циклу. Но петля обратной связи также служит для улучшения самого процесса разработки: Необходимо устранить отходы, задержки и другие препятствия для повышения производительности.
- Максимальное расширение прав и возможностей тех, кто выполняет работу: В идеале люди сами принимают решения и несут за них ответственность. Когда команда или даже отдельный работник может, хочет и уполномочен решить проблему, не дожидаясь действий извне, работа выполняется гораздо быстрее.
- Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают выстроить процессы таким образом, что сотрудники становятся свободнее и счастливее на работе, видят, что их труд востребован клиентами, ценят оказанное им доверие и возможности для саморазвития. Люди с внутренней мотивацией работают более эффективно, особенно когда работа сложная и творческая.
Эти 6 характеристик являются общими для многих agile-подходов при правильной реализации. Давайте теперь подробнее рассмотрим, что представляют собой эти agile-подходы.
На наш взгляд, agile-разработка основана на достаточно хорошо понятных и общепринятых ценностях. Поэтому имеет смысл применять эту философию ко всем компаниям, где вы устанавливаете систему управления проектами. Вам не нужно говорить вслух, насколько хорошо мы работаем в области agile-разработки.
Нюансы внедрения
Основная идея agile-разработки — это итеративный, пошаговый прогресс. Лучший способ внедрить методологию в организации: провести эксперимент с небольшим проектом, собрать отзывы участников. Хорошо, если владельцем продукта является сама компания, а не внешний заказчик. После устранения ошибок концепция может быть расширена. Также необходимо выбрать правильные инструменты управления проектами. Самое главное — строго придерживаться принципов agile-разработки и не пытаться отклониться от принятого направления, даже если возникают проблемы.
Самым важным условием для внедрения является непредусмотрительность. Члены команды должны всегда оглядываться на уже пройденные этапы, чтобы выяснить, какие инструменты сработали, а какие нет, и затем внести улучшения. Важно, чтобы все сотрудники были вовлечены в обсуждение. С другой стороны, окончательное решение должен принимать менеджер-владелец продукта.
Какие вопросы решает методика?
Практики Agile-разработки руководствуются двенадцатью принципами гибкой разработки программного обеспечения. Специалист, который знает и активно применяет их, может решить все проблемы и устранить потенциальные риски.
- Удовлетворять требования рынка путем своевременного и непрерывного развития продукции.
- Не сопротивляйтесь постоянным изменениям.
- Сосредоточьтесь на процессе разработки программного обеспечения, на качестве, а не на программировании.
- Активно взаимодействуйте с получателями продукта, не только с администраторами, но и с обычными разработчиками.
- Создайте подходящую рабочую среду, этическую поддержку команды разработчиков, разработайте систему поощрений.
- Если у продукта только один автор, он или она должны поделиться опытом.
- Контроль за ходом выполнения работы должен осуществляться с использованием измеримых критериев.
- Непрерывное развитие. Даже если члены команды прошли базовое обучение, они должны регулярно пополнять свои знания в области управления проектами.
- Выделяйте ресурсы не только на техническое совершенство, но и на планирование.
- По возможности упростите структуру коммуникаций в рамках проекта.
- Поощрять самоконтроль и самоорганизацию среди внедряющих агентств.
- Обеспечить устойчивое, многоуровневое развитие.
Система agile — это возможность вывести работу организации на новый уровень.
Плюсы и минусы использования гибкой методологии
После изучения информации может показаться, что agile-методы идеально подходят для решения различных задач. На самом деле эта система имеет множество преимуществ:
- Заказчики, менеджеры разных уровней, имеют представление о ходе работ на всех этапах,
- Плательщики могут рассчитывать на получение рабочего плана или предложения, соответствующего их ожиданиям,
- Разработчики положительно относятся к постоянно меняющимся требованиям,
- Нет необходимости выполнять всю работу с нуля,
- Постоянное, конфиденциальное общение с клиентом позволяет быстро получить ответы на интересующие вас вопросы.
Однако этот метод имеет некоторые недостатки. Хороший руководитель всегда должен выбирать наилучший подход для каждой задачи. Иногда ценности agile мешают. Например, отсутствие подробной документации процесса может привести к тому, что члены команды будут использовать различные инструменты, не зная, «окупятся» ли эти усилия до завершения текущего цикла разработки проекта.
Гибкость зародилась в сообществе специалистов по планированию. Старые методы организации рабочего процесса уже не позволяли быстро и эффективно разрабатывать программное обеспечение. В 2001 году единомышленники представили миру новый алгоритм управления, которому не хватало медлительности традиционных методов.
«Сделано» – лучше, чем «идеально»
Одним из ключевых отличий agile-методологии является ее нацеленность на результат. Команда agile не тратит время на документацию и ненужное планирование. Они сразу же приступают к разработке и стремятся быстро предоставить рабочую демонстрацию — прототип, который клиенты могут самостоятельно оценить на ранних стадиях реализации концепции.
При применении agile разработчики реализуют функцию за функцией. Каждая фаза разработки называется итерацией. Это занимает столько же времени и должно привести к появлению новой функции (или набора функций) в разрабатываемом продукте.
Итерации ускоряют разработку и позволяют вывести функциональное приложение на рынок за гораздо меньшее время, чем при использовании классических методов.
Как организована Agile-команда
В agile-команде почти все сотрудники имеют равные права. Вместо вертикальной иерархии используется горизонтальная система. Даже владелец продукта — не начальник, а носитель информации о конечном результате. Он не выше и не ниже обычных программистов.
В такой команде коллективная ответственность должна быть такой, чтобы каждый разработчик участвовал в развитии проекта, вносил идеи, распределял задачи и т.д., без «приказов сверху».
Важной характеристикой члена agile-команды также является желание расширять свои навыки. Разработчики помогают маркетологам, маркетологи погружаются в код. Все работают в тесном сотрудничестве, чтобы улучшить конечный продукт.
Как внедрить Agile в свою компанию
При внедрении agile-разработки откажитесь от текущих принципов работы и внесите три ключевых изменения в деятельность команды:
Отмените традиционную иерархию и сделайте всех разработчиков, маркетологов и менеджеров лично ответственными за продукт и его развитие.
Заставьте всех работать в итерационном режиме, с каждой итерацией привнося что-то новое и в то же время значимое в разрабатываемый продукт.
Четко объясните клиентам и начальству новый способ работы и расскажите о его преимуществах, чтобы в дальнейшем не возникало недоразумений.
Вначале перемены сильно повлияют на привычный темп работы. Классическая методология не покинет вас сразу, и вы будете постоянно о ней вспоминать, но после нескольких итераций преимущества перехода на новую методологию будут заметны.
Если вы хотите использовать здесь подход agile, вам придется собрать пять проектных команд, что в итоге приведет к пяти совершенно разным, уникальным домам (а это не то, чего хочет клиент). Поэтому данный метод не подходит для повторения.
Примеры Agile
Чтобы проиллюстрировать разницу между классическим подходом и гибкой методологией, рассмотрим случай с небольшой пекарней. В первом случае управление осуществляется на основе стандартной системы, а во втором — после внедрения гибкого управления.
№ 1: Стандартная модель управления пекарней
Технолог должен разработать новый вид пирога. Даже если есть исследования предпочтений клиентов, технолог, скорее всего, будет руководствоваться пожеланиями своего руководителя. В такой компании менеджер решает, пойдет ли новый рецепт в производство. В такой системе технолог разрабатывает только одну версию, которая утверждается или отклоняется. Чтобы торт попал на полки магазинов, рецепт должен понравиться генеральному директору.
Описанная выше ситуация является классической для российских компаний. В этом случае сотрудники умеют выполнять только точные инструкции, а решения принимаются одним, максимум тремя людьми.
№ 2. Кондитерская с гибким подходом.
Менеджер решает, что пришло время ввести новый вид пирога. Для решения проблемы они привлекают маркетологов, технолога, бухгалтеров, менеджеров по продажам, обычных кондитеров и, конечно же, покупателей. Конечный результат — продукт, который нравится конечному потребителю.
В этой системе почти нет иерархии. Все в равной степени участвуют в обсуждении результатов каждого рабочего цикла. Гибкая система позволяет сотрудникам сосредоточиться на одной цели и помогает создать продукт, который действительно пользуется спросом. Гибкий подход экономит время, повышает рентабельность и позволяет решать проблемы на ранней стадии проекта.
Методы управления Agile чаще всего используются в бизнесе и ИТ. Он также используется в маркетинге и образовании. Agile используют многие государственные и коммерческие организации, такие как ReturnPath (компания по разработке программного обеспечения), Oreo (известный производитель печенья), пенсионный фонд в Норвегии и крупный агрегатор авиабилетов Aviasales.
В России Agile был успешно опробован в банковском секторе в отдельных командах, например, в Сбербанке и Альфа-Банке. Agile-подход также используется в команде бухгалтерского сервиса «Кнопка» и сети пиццерий «Додо Пицца».
Однако у крупных организаций (таких как Альфа-Банк) больше возможностей для применения agile-разработки. Но именно небольшие компании называют этот метод одним из ключевых факторов успешного продвижения на рынке.
Как внедрить Agile в свою компанию: пошаговая инструкция
Действия, необходимые перед внедрением Agile
Во время перехода следует найти баланс между традиционными и agile-методами управления, чтобы команда могла адаптироваться.
Основные методы Agile обычно включают:
Совместное решение проблем. Клиент, менеджер и члены команды работают вместе, чтобы обеспечить общее понимание цели и обмен информацией.
Визуальный осмотр. Сотрудники, участвующие в проекте, используют карточки с цветовой кодировкой или другие индикаторы, чтобы показать статус области проекта (например, «запланировано», «разработано», «завершено»).
Адаптивное управление. Роль менеджера заключается не в том, чтобы давать задания, а в том, чтобы следить за выполнением правил сотрудничества.
Фрагментация проекта на циклы. Это позволяет команде сосредоточиться на задачах конкретного этапа.
Адаптация продукта. В каждом цикле команда анализирует ошибки и накапливает опыт, чтобы избежать ошибок в следующей итерации.
Рекомендуется использовать метод agile, если команда готова к нему, т.е:
есть четкая цель проекта и конкретный срок ее достижения,
большой объем работы можно разделить на несколько этапов,
Был проведен анализ потребностей целевой аудитории,
определен сбор данных и определены показатели для измерения результатов,
клиент готов активно участвовать в процессе,
команда состоит до 10 человек.
Гибкий этап внедрения
С чего начать?
Анализ потребностей населения. Для команды важно знать, кто будет использовать их продукт и почему. Критерии должны быть релевантными и измеримыми. Важна обратная связь с целевой группой.
План. Во время организационного собрания вы должны сформулировать идею проекта, распределить ресурсы и установить сроки, разбив проект на небольшие этапы.
Создание команды. Набрать персонал для проекта, распределить задачи и утвердить график встреч.
Выберите методы распределения заданий, отчетности и анализа.
Обучить персонал принципам гибкой разработки. Чтобы быть эффективным, каждый член команды должен понимать и разделять основные идеи agile-разработки.
Тест-драйв. Этот этап лучше всего проводить под руководством эксперта, чтобы уточнить роли и проиллюстрировать цикличность работы.
Бегущий спринт. После каждого этапа оценивается результат и корректируется дальнейший план.
Создание конечного продукта.
Agile-управление проектами значительно повышает эффективность организации за счет регулярной корректировки стратегии между циклами и контроля результатов на каждом этапе. Однако внедрение подхода agile management требует согласованности с поставленной целью и готовности менеджера действовать в гибких рамках.
Ниже мы рассмотрим некоторые нюансы применения agile-методик в маркетинге.
Вам не нужно полностью отказываться от своих планов и стратегий. Гибкость позволяет более гибко использовать традиционные маркетинговые методы. Главная цель всегда остается неизменной: максимальная доля рынка для компании.
С другой стороны, Scrum — это методология. Существует четкое распределение ролей в команде, определенный набор действий и алгоритмов, нарушение которых разрушает работоспособность команды. Но agile-методологии не имеют конкретных процессов, элементов и правил. Существуют всеобъемлющие ценности и общие принципы.
Заключение
Использование agile-методологии может повысить эффективность компании за счет лучшего контроля рабочих циклов и своевременной адаптации стратегии. Внедрение методологии agile-менеджмента требует адаптации к конкретной задаче и отличной подготовки менеджеров компании.
Выводы по статье:
- Управление проектами Agile основано на взаимодействии между членами команды, клиентами и потребителями.
- Все задачи разделены на этапы с четкими сроками выполнения.
- Команда должна быть готова к внесению изменений в конце каждого цикла.
Не пропустите обновления! Следите за новыми возможностями в социальных сетях и на рекламных площадках — подпишитесь на наш Telegram-канал. Мы предлагаем самые свежие новости, на которые вам нужно подписаться: смотрите, какой канал рекламы.
Главная особенность заключается в том, что на каждом промежуточном этапе у команды есть рабочий продукт, даже если он требует изменений и дополнений, но он готов к работе.
Ключевые моменты в применении Agile
Гибкая система подходит для различных секторов экономики. Но прежде чем внедрять его, необходимо «разложить по полочкам» последовательность его практического применения.
Распределение ролей по Agile
Роли распределены следующим образом:
- Владелец продукта. Он не вдается в технические подробности процесса, но имеет четкое представление о том, зачем и для кого создается продукт.
- Координатор. Организует рабочий процесс и дает правильное направление действиям сотрудников.
- Команда экспертов. Технические разработчики продукта.
Система иерархии в Agile
Субординация горизонтальная, но существует иерархия, основанная на навыках тех, кто участвует в процессе, а не на степени полномочий. Направление действий, необходимых для решения поставленных задач, определяет руководитель.
Пропускная способность процесса
Он относится к количеству «пользовательских историй», которые были реализованы. Например, клиент определяет задачу по созданию фильтра поиска в приложении, добавлению формы обратной связи, упрощению порядка обращения в техническую поддержку и т.д. Производительность показывает, сколько пользовательских историй было завершено за неделю.
Порядок установки приоритетности и последовательности выполнения задач
На данном этапе важен раздел о деятельности. В частности, это может быть первый пункт:
- Основанные на ценности. То есть оценивается, является ли работа выгодной и полезной для компании, помогает ли она улучшить репутацию компании и решить проблемы пользователей.
- Технология, основанная на риске: она оценивает технологический риск, связанный с выполнением задачи. Например, слишком много требований или велико влияние внешних факторов и т.д.
График выполнения задач
Существуют специальные приложения с шаблонами для планирования проектов. Одним из примеров является служба GanttPRO. Он содержит шаблоны для определения задач, создания графиков (которые позволяют увидеть, на каком этапе реализации вы находитесь) и конкретно указывает на слабые места в проекте.
Внедрение методологии Agile
Заявка включает в себя несколько этапов. Сначала излагается основная методология, затем определяются цели, сроки и состав команды. Руководители должны осознать ценность внедрения agile-методологии в компании, а сотрудники должны быть обучены работе с новой методологией.
Привлекайте людей, которые уже имеют опыт работы с agile-процессом, к выбору команд, инструментов и аналитических методов.
Когда не следует применять метод Agile
Agile-технологии, конечно, очень эффективны, но они подходят не всем и не всегда. Как определить, имеет ли смысл использовать этот метод для конкретного проекта или компании?
Когда не стоит использовать Agile
Вот четыре примера, когда не имеет смысла использовать agile-разработку:
- Результат проекта четко определен и не может быть изменен.
В agile весь проект делится на итерации, что позволяет дешевле вносить изменения и исправлять спорные вопросы. Но если задачи четко определены, то не может быть ни сомнений, ни изменений. Тогда Agile не имеет никакой пользы. Если проект подчиняется строгим правилам и четким требованиям, то нет необходимости в различных вариациях планирования задач.
- Первоначальная цель — повторять результаты проекта снова и снова
Определение проекта: «ограниченный по времени ряд действий с началом и концом, направленных на создание уникального продукта, услуги или результата». Пример: клиент заказывает строительство пяти одинаковых домов для отдыха.
Если вы хотите использовать здесь подход agile, вам придется собрать пять проектных команд, что в итоге приведет к пяти совершенно разным, уникальным домам (а это не то, чего хочет клиент). Поэтому данный метод не подходит для повторения.
- Заинтересованные стороны отказываются использовать гибкость
Одним из принципов agile-разработки является постоянное взаимодействие между сторонами, участвующими в проекте. Но не все и не всегда хотят и могут это делать. Если риски проекта минимальны, а стоимость проекта невысока, имеет смысл сотрудничать традиционным способом — только в ключевых точках и на этапе приемки.
- Они еще не готовы к использованию Agile.
Это означает, что компания или члены проектной команды могут быть не готовы. Тогда использование методологии разработки Agile чревато ненужными рисками.
О том, что компания не готова к внедрению Agile, можно судить по следующим пяти признакам:
- Члены команды разработчиков не обучены или не полностью понимают принципы, методы и модели разработки Agile, что означает, что они не могут в полной мере использовать инструмент.
- Заинтересованная сторона (заказчик, инвестор, исполнитель) не хочет использовать подход Agile. Это следует обсудить до начала работы над проектом.
- У вашей компании нет возможности взаимодействовать на ежедневной основе. Тогда сотрудничество, скорее всего, не будет плодотворным, и от гибкости придется отказаться.
- Между отделами компании нет тесного сотрудничества. При внедрении agile-разработки необходимо тесное сотрудничество и совместные встречи и обсуждения деталей проекта. В противном случае вы не сможете рассчитывать на успех в реализации.
- Компания перегружена документацией, правила требуют, чтобы каждое действие было задокументировано в серии отчетов. Тогда Agile может стать очень дорогим. Сокращение количества отчетов, требований и контрольных списков занимает важное место в списке принципов Agile-разработки, приведенном выше.
Книги про Agile
- Роб Коул и Эдвард Скотчер, «Brilliant Agile — управление проектами с помощью Agile, Scrum и Kanban». Подходит для всех, кто решил внедрить agile-управление проектами в своей организации.
- Стивен Деннинг, «Эпоха Agile. Как умные компании трансформируются и добиваются результатов». Автор показывает, как ставить и достигать цели на всех уровнях управления, используя методы agile.
- Джефф Сазерленд, «Скрам. Революционный метод управления проектами» Рамка Scrum — это только его детище. Книга подходит для Скрам-мастеров, которые хотят понять этот инструмент и использовать его в своей работе.
- Хенрик Книберг и Маттиас Скарин: «Скрам и Канбан: как извлечь максимум пользы». По сути, это сравнение двух методов, описание их сильных и слабых сторон и примеры их использования.
- Сборник статей экспертов компании Toyota под названием «Канбан и Just-in-Time в Toyota. Управление начинается на рабочем месте». В ней описывается процесс внедрения Канбан в компании со смесью американской и японской систем управления. В нем описывается, как в результате изменились внутренние процессы.
- Майк Кон: «Agile: Оценка и разработка проекта». Независимо от типа проекта, планирование и оценка должны иметь место. Конечно, иногда планы недостаточно реалистичны. Автор книги знает Agile по имени. Он учит, как применять методологию к проектам разного масштаба, как грамотно их планировать и как их оценивать.
Принципы Agile позволяют компаниям быстро достигать поставленных целей, разрабатывать продукты, которые хотят клиенты, учитывать все пожелания (благодаря быстрой обратной связи) и вносить соответствующие коррективы. Это укрепляет лояльность клиентов и помогает строить долгосрочные и продуктивные отношения.
