Agile scrum что это кратко

Обновлено: 06.07.2024

В русскоязычных книгах и статьях Agile (Аджайл) часто называют гибкой методологией разработки. Если считать методологией семейство разных методов и методик разработки программного обеспечения, то это почти правда: Agile действительно создан как обобщение разных подходов к разработке ПО. Однако …

Стоит разделять Agile как семейство гибких подходов и Agile как философию и систему ценностей. В этой статье я лишь кратко опишу самые популярные подходы (Scrum и Kanban), а более подробно рассмотрю второй аспект: зачем нужны ценности Agile, что стоит за ними, где их можно применять и каково место Agile в общей картине управления процессами, продуктами и бизнесами.

Чем Agile отличается от методологий

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий. RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

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

Метод — это способ достижения какой-либо цели.

В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.

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

Ценности Agile простыми словами

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

Посмотрим, зачем нужны эти ценности Agile.

1. Люди и их взаимодействие важнее процессов и инструментов

Чтобы люди работали эффективнее, процессы и инструменты не должны их ограничивать. В Agile ни процесс, ни тем более программный инструмент не диктует, что людям делать. Более того, они сами решают, как менять процессы/инструменты своей работы.

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

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

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

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

3. Сотрудничество с заказчиком важнее согласований условий контракта

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

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

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

4. Готовность к изменениям важнее, чем следование плану

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

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

Agile — философия, Scrum — ее реализация

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

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

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

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

Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т.д.
И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

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

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

Кратко о том, что входит в Agile сегодня

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

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

Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.

Канбан отличается от Скрама по многим параметрам, в частности:

имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
нацелен не только на ускорение, но и на равномерность процессов;
имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

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

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.

Область применения Agile

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

Судя по числу участников исследования Agile в России 2019, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

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

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

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

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Книги об Agile по-русски

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

Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban.

Авторы: Роб Коул, Эдвард Скотчер

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

Эпоха Agile. Как умные компании меняются и достигают результатов.

Автор: Стивен Деннинг

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

Scrum. Революционный метод управления проектами.

Автор: Джефф Сазерленд

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

Резюме. Место Agile среди родственных управленческих подходов

Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.

Это слово сейчас имеет два основных значения:

Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

С другой стороны, Agile — это про организацию процесса разработки, а не про технические детали реализации, зависящие от индустрии. Например, в IT-индустрии с той же целью (быстрая поставка ценности клиенту) применяются так называемые инженерные практики и DevOps, но они в Agile не входят.

сократить время вывода продуктов на рынок / время их поставки потребителю;
ускорить принятие решений на уровне команд и выше.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2010-х годов. В гибкость бизнеса входит не только быстрая поставка ценности клиентам и быстрая реакция на изменения, но также гибкость целеполагания и распределения ресурсов в организации.

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

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

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

Статьи по теме Scrum

Спринты

Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.

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

Планирование спринта — это событие в scrum, в рамках которого определяется объем работы на следующий спринт и критерии выполнения этой работы.

Развеиваем мифы о четырех agile-собраниях

Узнайте, как проводить первоклассные agile-собрания, такие как планирования спринта, ежедневные стендапы, обзоры итогов итерации и ретроспективы.

Бэклог продукта — совершенный список задач

Что такое бэклог продукта в agile или Scrum? Ознакомьтесь с рекомендациями по управлению успешным бэклогом продукта и расстановке приоритетов.

Три шага к эффективному обзору итогов спринта

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

Стендапы для agile-команд

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

Кто такой scrum-мастер?

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

Ретроспективы agile: используйте прошлое, чтобы определять будущее

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

Agile-роли в scrum

Узнайте об обязанностях и объеме работ, связанных с тремя основными agile-ролями в scrum: scrum-мастер, владелец продукта и команда разработчиков.

Scrum of scrums

Scrum of scrums — это масштабируемая agile-техника, предлагающая способ объединения нескольких команд, которые должны работать вместе для поставки сложных решений. Узнайте, как масштабировать доску Scrum с помощью примеров от Atlassian и других экспертов.

Изучите scrum с помощью Jira Software

Пошаговое руководство по ведению scrum-проекта, расстановке приоритетов в бэклоге, упорядочиванию работы в спринты, проведению scrum-собраний, другим вопросам — и все это в Jira.

Сделайте команду сплоченнее с помощью Scrum-досок Jira

Scrum-доска Jira визуально отображает прогресс по ходу разработки.

Платформа

Понятия Scrum и Agile часто путают, потому что Scrum строится вокруг идеи о постоянном совершенствовании, которое является главным принципом Agile. И все же Scrum — это методика работы, а Agile — это образ мышления. Перейти на Agile не так-то просто; вся команда должна стремиться изменить свой подход к созданию ценности для клиентов. Но можно просто начать использовать методику, такую как Scrum. Это направит мышление в нужное русло и поможет практиковать принципы Agile в повседневном общении и работе.

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

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

Артефакты Scrum

Сначала определим три артефакта Scrum. Артефакт — это то, что мы создаем, например инструмент для решения проблемы. В Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Эти три постоянные присутствуют в каждой команде Scrum, мы постоянно к ним обращаемся и уделяем им время.

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

Собрания или мероприятия Scrum

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

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

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

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

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

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

Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

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

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

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

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

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

Они решают, когда поставить продукт, стремясь делать это как можно чаще.

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

Scrum-мастер

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

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

Команда разработчиков Scrum

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие популярные методики, например Kanban. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

Scrum строится вокруг небольших итераций с фиксированной продолжительностью. Сначала нужно определить продолжительность спринта, после чего выбрать пользовательские истории или элементы бэклога продукта, которые можно реализовать в течение этого цикла спринта. В Kanban же количество заданий (или объем невыполненной работы — лимит WIP), которые нужно выполнить в текущем цикле, задается изначально. Затем ведется обратный отсчет времени, которое уйдет на реализацию этих возможностей.

У методики Kanban нет структуры, присущей Scrum. В ней есть лимит WIP, но все остальные аспекты можно в той или иной мере изменить по вкусу. В Scrum же присутствует несколько строго определенных понятий: обзор итогов спринта, ретроспектива, ежедневное Scrum-совещание и т. д. Scrum также требует формирования многофункциональной команды, чтобы возможность достижения цели не зависела от сторонних участников. Собрать междолжностную команду — задача не из легких. В этом плане Kanban проще адаптировать, а применение Scrum влечет за собой коренное изменение образа мышления и особенностей деятельности команды разработчиков.

За что мы любим Scrum?

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

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

И все же, чтобы освоить Scrum, может понадобиться какое-то время, особенно если команда разработчиков привыкла к стандартной каскадной модели. Новой команде предстоит выбрать scrum-мастера, освоиться в мире коротких итераций, ежедневных scrum-собраний и обзоров итогов спринта. Это может стать настоящим сотрясением основ.

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

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

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

Гибкие подходы

Ценности Agile:

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

Agile-манифест — основной документ эджайлистов, созданный в 2001 году, в котором описаны ценности и принципы гибкого подхода.

Принципы Agile

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

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

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

Как в Agile отслеживается прогресс проекта? Работающим программным обеспечением. Этот пункт включает в себя все предыдущие. Без успешной реализации каждого предыдущего этапа и следования каждому из принципов, на которых базируется Agile, работающего ПО не выйдет.

Scrum

Scrum-команда: можно ли накормить всех двумя пиццами

Некогда Джефф Безос, создатель Amazon, установил правило: каждая внутренняя команда должна включать в себя такое количество сотрудников, чтобы их можно было накормить двумя пиццами. Дело в том, что продуктивно работать и сотрудничать друг с другом можно, только если в команде будет немного людей. Скажем, 5-9.

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

В такой команде существует 3 роли:

product owner (владелец продукта), который по сути выступает в роли голоса заказчика;
scrum-мастер — мастер-джедай, который координирует работу в команде и является своеобразным мостом между продакт оунером и командой разработки;
команда разработки — самоорганизующаяся и кросс-функциональная .

Итерации: почему спринты, а не рабочие недели

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

Скоуп (scope) — содержание проекта: что, каким образом и для кого должно быть сделано, чтобы проект считался реализованным.

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

Цель фреймворка — закончить спринт, в идеале выполнив все задачи. Самое главное — предоставить клиенту рабочую версию продукта на демо. Бывает, что какую-то из задач не успевают реализовать. Если для того, чтобы фича работала, эта задача не обязательна, не страшно : она перенесётся на следующий спринт.

Митинги: трата времени или важная стратегическая часть Scrum-а

Sprint planning meeting

На этом митинге решается судьба. Нет, не человечества — спринта. На нём присутствуют Scrum-мастер, Product Owner и команда разработки. Владелец продукта рассказывает, какой результат хочет видеть в конце спринта. Разработчики выясняют нужные моменты во избежание миллиона вопросов, которые могут появиться в процессе. Команда разбирается с нагрузкой. Исходя из всего этого определяется цель спринта. Так проходит первая часть митинга. Во второй части команда составляет спринт бэклог — задачи, которые нужно реализовать.

Длительность митинга зависит от длительности спринта. На собрание по планированию выделяется по 2 часа на каждую неделю в спринте. Если определяем, что спринты будут длиться 2 недели, то на планирование нужно выделить 4 часа. Если весь кофе выпит, спина заболела от долгого сидения на митинге, а длительность перевалила за 8 часов — что-то пошло не так. Задумайтесь: это случайность или есть тенденция затягивать собрания? В случае закономерности скорее всего ваш Scrum нужно масштабировать .

Daily Scrum Meeting

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

Так как Scrum-команда кросс-функциональна, все участники взаимосвязаны. Легче за какие-то 15-20 минут разобраться, кто и как связан в задачах, к кому идти и кто от кого что сегодня ждет, чем на протяжении дня пинговать всех на свете.

Вопросы, которые хоть и повторяются из митинга в митинг, но которые очень помогают понять текущую ситуацию по прогрессу:

Что было сделано?
Что запланировано?
Есть ли проблемы, и что может помочь?

Sprint review meeting

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

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

Sprint retrospective meeting

Что было хорошо?
Что было плохо?
Что можно улучшить?

Ретро проводится в последний день спринта. Не существует каких-то четких временный рамок. Обычно на этот митинг потребуется 45 минут, умноженные на количество недель в спринте.

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

Kanban

Если Scrum — структурный подход, то Kanban можно назвать подходом баланса. Визуальный метод, благодаря которому предельно ясно, за что нужно браться в первую очередь. Здесь целью являются выполнение задачи. Изменения и смещения по плану принимаются безболезненно. Никого пиццами кормить не нужно. В Kanban-е нет ограничения по количеству человек в команде и по длительности итераций, нет командных ролей и обязательных митингов. Что есть вместо этого? Обо всём по порядку.

Командные роли: есть кто живой

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

Процесс: бездедлайновый хаос

Доска Kanban

Свидетели доудалённого периода еще помнят доску Kanban в физическом виде — доску, на которой происходило распределение задач с помощью стикеров или маркера. Сейчас в основном используются электронные варианты.

Движение задач на доске происходит слева направо: от статуса To Do, где собраны все задачи для реализации, до Done, где задачи достигают своеобразного дзена. Когда все задачи перейдут в колонку Done, считается, что проект готов.

Статусы Kanban

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

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

Что лучше: Agile, Scrum или Kanban

Agile, Scrum и Kanban объединяет мысль о том, что люди — ключевое звено проекта. Помимо взаимоотношений всегда будут принципы, которые будут важны одной команде и абсолютно безразличны другой. Это и отличает их друг от друга.

Ниже в таблице сравним основные артефакты, которые разнятся в Scrum-е и Kanban-е. Их принципы базируются на Agile, поэтому нет смысла сравнивать базу и два фреймворка, которые вытекают из этой базы.

Agile, Scrum и Kanban — иголки в стоге подходов и фреймворков. Возможно ни один из тех, о которых говорили в статье, не подойдет для вашего проекта. Не стоит отчаиваться: существует еще много других на вкус и цвет любого PM-а. О них подробно рассказывают спикеры на курсе Dao PM. Практикующие PM-ы делятся кейсами из практики, впечатлениями от работы в том или ином подходе, еще и визуально показывают, как это работает в реальной жизни.

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

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

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

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

Scrum процесс на одном листе

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

Артефакты в Scrum

В скрам используется всего четыре артефакта:

Product Backlog
Sprint Backlog
Sprint Goal
Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

Project Backlog (JIRA)

Получить стоимость обучения Agile/Scrum за 60 минут?

Sprint backlog:

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

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

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

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

Sprint Burndown Chart

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

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

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

Product Owner
Scrum Master
Team.

Роль Product Owner

формулирует требования
приоритезирует требования
корректирует приоритеты на каждом спринте
несет персональную ответственность за ценность требований для рынка/пользователей
отвечает за взаимодействие с рынком
только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

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

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
организует работу команды и обеспечивает её всем необходимым
защищает команду, несёт ответственность за её эффективность
только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

Скрам мастер не назначает людей на задачи – это делает сама команда;
Мастер не заставляет людей делать работу – это ответственность команды;
Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

кросс-функциональная
взаимозаменяемая
самоорганизующаяся
с фиксированным составом (в ходе спринта)
4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

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

Команда НЕ принимает решений:

какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

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

Ритуалы (процессы в Scrum)

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

Ритуалы в скрам это:

Sprint Planning Meeting
Daily Meeting
Sprint Review
Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

выполняется всей командой перед началом спринта
команда выбирает требования из Product Backlog и формирует Sprint Backlog
если требуется учесть взаимосвязи между операциями, то это делается здесь
команда декомпозирует требования на задачи (tasks)
каждая задача проходит оценку в трудозатратах или универсальных единицах
во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

представление и пояснение Product Owner’ом списка требований
вопросы со стороны команды
/рекомендуется перерыв/
декомпозиция требований на задачи (tasks)
оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

проходит ежедневно и только в одно и то же время;
встреча проходит только стоя;
поэтому длительность встречи не более 15 минут;
чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Kanban Board во время спринта

Sprint Review – сдача спринта Product Owner

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

Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.

команда зачитывает требования из Sprint Backlog
по каждому критерию приемки происходит демонстрация полученных результатов
каждый вопрос со стороны Product Owner’а записывается, чтобы иметь возможность ответить на них позже
каждое новое требование Product Owner’a выписывается, чтобы позже включить его в Product Backlog.

На встрече могут присутствовать любые сотрудники организации или просто заинтересованные лица. Важно, чтобы право голоса имели только участники Scrum процесса (Produt Owner, Team, Scrum Master).

Никаких презентаций в PowerPoint на встрече, если вы правильно меня поняли!

Retrospective

Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.

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

какие решения должна принять команда, чтобы сделать процесс более предсказуемым?
какие проблемы мешают команде выполнять взятые на себя обязательства?
как улучшить взаимодействие с Product Owner’ом?
какие ошибки совершает команда и почему.

Решения должны быть записаны на отдельной доске. После всеобщего голосования решения принимаются к исполнению со следующего спринта. Scrum Master контролирует ход встречи и следит за её регламентом.
Ознакомьтесь со списком наших курсов по управлению проектами.

Почему появился Agile?

Теперь немного слов о том, как и зачем появился этот подход? История возникновения этого подхода стала ответом на запросы отрасли:

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

В начальной фазе проекта заказчик не может сформулировать исчерпывающие требования к продукту. Этому есть несколько причин:

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

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

К середине 90-х разрабатываемое ПО было в основном десктопным и его требовалось устанавливать на каждый отдельный компьютер (например, MS Word). С появлением веб-приложений внедрение новой функциональности стало происходить быстрее: требовалось развернуть приложение только на сервере и все пользователи получали к нему доступ. Эта инновация серьезно усилила конкуренцию между компаниями: тот, кто применил новую технологию раньше других – выигрывает рынок и клиентов.

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

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

Основная идея agile – сотрудничество с заказчиком важнее, чем контрактные обязательства. И поэтому agile-методы стремятся к уменьшению объема документации. Это позволяет Заказчику платить только за результат, имеющий ценность для бизнеса.

При этом agile не отказывается от формулирования требований. Заказчик (в agile – владелец продукта, product owner) предъявляет требования в упрощенном виде и на сценариях работы пользователей.

Резюме

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

Читайте также: