Фреймворк и методология разница
Это пятая статья из серии «Введение в Agile». В ней мы расскажем о самом популярном подходе в области Agile – фреймворке Scrum.
До этого мы разбирались в отличиях гибких и классических подходов к управлению, области применения Agile-подходов, характеристиках Agile-команды и способах перехода на Agile:
Что такое фреймворк
Первый вопрос, который возникает при виде словосочетания «фреймворк Scrum»: а что такое фреймворк и чем он отличается от стандарта или методологии?
Термин «фреймворк» (от англ. framework) чаще используется в области разработки программного обеспечения и означает набор базовых элементов и правил, своего рода каркас, на котором строится процесс разработки. В отличие от стандарта, этот перечень правил более общий и не содержит детальных описаний отдельных шагов, инструментов или шаблонов документов. В отличие от методологии, фреймворк более требователен к соблюдению включенных в него правил.
Немного истории
Scrum (Скрам) был разработан в 1995 году Джеффом Сазерлендом и Кеном Швабером. Перед Сазерлендом была поставлена задача: менее чем за 6 месяцев разработать замену основному программному продукту компании «Easel Corporation». Прочитав все, что смог найти о повышении производительности команд, Джефф предложил свой подход. Он объединился со своим коллегой Кеном Швабером для формализации подхода и в 1995 году Scrum был представлен всему миру.
Почему «Скрам»?
Название «Скрам» Сазерленд позаимствовал из регби. Так называется момент в игре, когда участники, обхватив друг друга руками, образуют тоннель, в который вбрасывается мяч. По аналогии, предложенной Сазерлендом, команда разработки объединяется, чтобы сконцентрировать усилия на продукте.
Преимущества Скрама
Скрам широко известен, так как его применяет большинство команд, работающих по Agile. По результатам 13-го ежегодного исследования State of Agile – 2019, Scrum остается самым популярным фреймворком. Однако следует понимать, что, как у любого подхода, у Скрама помимо сильных сторон есть и ограничения.
Среди преимуществ Скрама – четкость, простота и наличие единого официального источника информации. Все требования изложены в официальном Руководстве по Скраму (Scrum Guide) .
Ограничения Скрама
В то же время с применением Скрама связаны определенные сложности. В одной из предыдущих статей мы рассказали, что для работы в Agile нужна особая команда: небольшая, профессиональная, плоская (без иерархии и руководителей), которая сама принимает решения о способе достижения результата.
Эти же требования применимы и к командам, которые работают по Скраму: ответственность за результат в них распределена между участниками команды (у всех одна роль – «разработчик»), которые заведомо мотивированы на достижение этого результата. Этим сотрудникам не нужно каждый день ставить задачи и контролировать выполнение, они самостоятельно договариваются о том, как выстроить работу, и нацелены не на выполнение отдельных задач, а на создание законченного продукта или части такого продукта (инкремента), имеющих ценность для заказчика.
Структура фреймворка
Скрам состоит из 3 ролей, 5 событий и 3 артефактов (носителей информации о продукте). Каждый элемент Скрама взаимосвязан с другими и обязателен для применения. Общая схема фреймворка представлена на рисунке ниже. Мы кратко опишем весь процесс, а затем подробнее остановимся на каждом элементе.
Владелец продукта формирует Бэклог продукта – приоритизированный список требований. В дальнейшем Владелец продукта отвечает за соответствие разрабатываемого продукта требованиям пользователей.
Работа команды разработки делится на равные промежутки времени – спринты. Рекомендуемая длина спринта – от 1 до 4 недель. Количество спринтов не ограничивается. Проект может быть завершен когда Владелец продукта получил требуемый функционал, когда дальнейшая работа над продуктом не требуется или экономически не востребована.
При планировании очередного спринта Команда разработки формирует Бэклог спринта – фрагмент общего Бэклога продукта, содержащего по возможности самые приоритетные требования. Включая требование в Бэклог спринта, Команда разработки берет на себя обязательство реализовать это требование в ходе спринта.
Объем или количество требований, которые Команда может выполнить за спринт, определяется на основе опыта: в течение нескольких спринтов анализируются обязательства, которые взяла на себя Команда разработки при Планировании спринта, и фактический объем выполненных требований. Такой подход называется эмпирическим. В результате устанавливается условно-постоянный объем, который Команда стабильно прорабатывает за Спринт – производительность Команды.
После Планирования спринта запускается процесс Разработки, в ходе которого Команда разработки работает над требованиями из Бэклога спринта.
Для оперативного планирования и решения проблем ежедневно проводятся Скрам-встречи, или «летучки». На них участники Команды разработки обсуждают, что удалось сделать за прошедший день, что планируется на следующий, и какие возникли проблемы. Важная характеристика Скрам-встречи – ее жесткая ограниченность по времени. «Летучка» не должна занимать более 15 минут.
Отслеживание соблюдения ограничений процесса, помощь команде при выстраивании работы и разрешение конфликтов внутри команды – основные задачи Скрам-мастера.
После окончания Спринта проводится Обзор спринта. Это встреча, в которой могут участвовать все лица, заинтересованные в создании продукта, включая конечных пользователей и руководство организации. Цель встречи – продемонстрировать пользователям Инкремент продукта и получить обратную связь: насколько этот результат соответствует требованиям и ожиданиям. Термином «инкремент» в Скраме обозначается результат Спринта – работающий фрагмент продукта.
После Обзора спринта проводится Ретроспектива. В отличие от Обзора спринта, это закрытая встреча: в ней участвуют только разработчики, Скрам-мастер и Владелец продукта. На этой встрече обсуждается прошедший спринт с точки зрения организации работы, полученного опыта, выделения положительных событий и факторов, а так же возникших проблем и составляется план по улучшению процесса Скрам в следующем спринте.
Резюме
Скрам – это самый распространенный Agile-подход. Изначально Скрам был разработан для повышения производительности команд ИТ-сферы, но позже распространился за пределы ИТ. С одной стороны, этот фреймворк прост и понятен, но за простотой скрыты жесткие требования к соблюдению процесса и характеристикам команды. В следующей статье расскажем о ролях и артефактах Скрам, а также о практиках, которые дополняют Скрам.
В продолжение статьи о классическом PRINCE2 по запросу из комментариев попробовала сравнить ключевые методики управления проектами. Надеюсь, что получилось что-то полезное и при выборе подхода управления у читающих часть вопросов будут снята.
Краткие вводные:
PRINCE2 (Projects in a Controlled Environment) – структурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании.
PMBoK – фреймворк (свод знаний) по управлению проектами, разработанный в 1996 году Project Management Institute (PMI) в США.
ISO 21500:2012 «Guidance on project management» - международный стандарт, разработанный проектным комитетом ISO/PC 236 «Управление проектами».
Как можно заметить, первое главное отличие – собственное позиционирование в проектном управлении. Остальные основные отличия с некоторыми субъективными выводами приведены в таблице.
PRINCE2
PMBoK (6 издание, 2017г.)
ISO 21500:20112
Определение проекта
Временная организация, которая создается с целью предоставления одного или нескольких бизнес-продуктов в соответствии с утвержденным экономическим обоснованием проекта.
Временное предприятие, направленное на создание уникального продукта, услуги или результата.
Уникальная совокупность процессов, состоящая из контролируемых и управляемых видов деятельностей с датами начала и завершения, предназначенная для достижения определенных целей.
Процессы
7 процессов: Начало проекта, руководство проектом, инициация проекта, контроль стадии, управление границами стадии, управление созданием продукта, закрытие проекта.
49 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, мониторинг и контроль, закрытие.
39 процессов, объединенных в 5 групп процессов: инициация, планирование, исполнение, управление, завершение.
Предметные темы / группы (курсивом отмечены различающиеся темы)
7 тем:
1. Экономическое обоснование,
3. Управление качеством,
5. Анализ и управление рисками,
6. Управление изменениями содержания,
7. Принятие решений.
10 областей знаний:
1. Управление интеграцией проекта,
2. Управление содержанием,
3. Управление сроками,
4. Управление стоимостью,
5. Управление качеством,
6. Управление человеческими ресурсами,
7. Управление коммуникациями,
8. Управления рисками,
10. Управление заинтересованными сторонами.
10 предметных групп:
2. Заинтересованные стороны,
Жизненный цикл проекта
Структура стадий проекта:
1. Стадия инициации,
2. Последующие стадии (создание продуктов, соответствующих требованием),
3. Финальная стадия (приемка результатов, подведение итогов проекта).
Минимальное количество стадий в проекте – 2 (инициация и финальная).
Все проекты могут иметь следующую структуру жизненного цикла:
1. начало проекта;
2. организация и подготовка;
3. выполнение работ проекта;
4. завершение проекта.
В стандарте отсутствуют четкие требования/пояснения по стадиям проекта, стандарт определяет, что проект должен подразделяться на фазы, состав и содержание которых должно определяться потребностями управления и контроля.
Принципы
7 принципов (универсальны и не требуют обоснования):
1. Постоянная оценка целесообразности,
2. Учет предыдущего опыта,
3. Определенные роли и обязанности,
4. Управление по стадиям,
5. Управление по исключениям,
6. Фокус на продукте,
7. Адаптация к внешним условиям.
Шестое издание PMBoK основано на процессной составляющей с четкими входами, выходами и инструментарием.
Ожидается, что новое седьмое издание будет ориентировано на принципы.
ISO 21500 по аналогии с PMBoK основан на процессной составляющей.
Ответственность за результат проекта
Ответственный руководитель (куратор/спонсор проекта) полностью отвечает за успех проекта.
Менеджер проекта управляет проектом на ежедневной основе в рамках полномочий, делегированных Управляющим советом.
Руководитель проекта = единый ответственный за результат.
Руководитель проекта обеспечивает общее руководство и управление работами проекта и отвечает за получение результатов проекта.
Инструменты управления
В методологии отсутствуют примеры инструментов, данная область отдается на откуп Руководителю проектов.
Предоставляет расширенный список инструментов и методов по каждому процессу управления проектом.
Стандарт не описывает конкретных инструментов для реализации процессов управления.
Возможность гибкого применения
Допускает использование минимального количества документов с минимальным требуемым содержанием, гибкое использование метода с соблюдением всех 7 принципов позволяет подготавливать упрощенную отчетность и минимизировать процессы управления (с учетом целей и задач, которые соответствуют процессам PRINCE2).
Так как PMBoK является не методологией или стандартом, а фреймворком, его создатели рекомендуют использовать PMBoK для создания собственной методологии управления проектами в компании. При этом созданная методология должна учитывать особенности каждого отдельного проекта и позволять руководителю проектов изменять процессы управления в определенных пределах.
Описанные в стандарте процессы не должны применяться без изменений ко всем проектам или фазам жизненного цикла проекта. Руководитель проекта должен корректировать состав процессов управления конкретным проектом или фазой, отбирая подходящие процессы и условия их реализации. Такая адаптация должна выполняться в соответствии с существующими политиками организации.
Все мы знаем, что фреймворки Agile — это не волшебные пилюли от всех болезней Компании, но в то же время часто об этом забываем, полагаясь на моду, непрофессионалов или вовсе приступая к делу, не понимая, какие ценности несёт Agile и что сулят изменения.
Предлагаю рассмотреть на практике одну из самых известных Agile практик Scrum, чтобы понять, где они действительно не работают и почему это происходит. Уверена, это может помочь не допустить множество ошибок в начале пути и выстроить либо эффективный процесс, либо отказаться от идеи внедрения фреймворка Scrum. Задайте себе контрольные вопросы в начале каждого блока, чтобы понять, в каком направлении вы двигаетесь. Приступим!
В какой системе Вы существуете?
Ист. Кеневин (Cynefin): способ думать о ситуациях, проблемах, системах
Часто бывает так, что мы не знаем, когда применять Scrum и в какой среде он совершенно бессмыслен – а из-за этого “таких делов можно наворотить”. Да, Scrum нужен не всегда и не во всём. Чтобы узнать, подходит именно вам Scrum или нет, можно воспользоваться моделью «Кеневин» или Cynefin (англ. Среда обитания), которая позволяет компании определить, в какой системе она существует, а значит выбрать верную модель управления, коррелирующую с компетенцией команды. Разработал методику Дейв Сноуден, в прошлом возглавлявший Институт управления знаниями на базе IBM, а ныне сооснователь центра Cognitive Edge и консультант по вопросам менеджмента знаний.
Схематично модель построения систем представлена на рисунке, мы видим расположенные по периметру окружности, символизирующие системы:
• упорядоченные – простые и сложные;
• неупорядоченные, или комплексные;
• хаотичные.
В центре схемы – зона неопределенности, которую нужно как можно быстрее покинуть.
Опишу каждую подробнее, чтобы понять, в каких системах Agile и фреймворк Sсrum не подходят, а какая – та самая, в которой нужен именно Scrum.
1. Упорядоченные простые системы (Simple, Obvious)
Они понятны, для их решения у команды есть опыт. Уже на старте понятно, что получится в результате, за какие деньги и в какие сроки. Нередко есть инструкция по выполнению этого действия. Самый простой пример – сборка комплектующих на заводе или производство стульев.
Формула принятия решений также проста: Определяем – Классифицируем – Реагируем.
2. Упорядоченные сложные системы (Complicated)
В этом случае заранее не понятно, как решать проблему. Задача не уникальна, однако именно ее команда ранее не решала. Показательным может быть пример создания типового сайта, у команды есть согласованное ТЗ от заказчика, шаблон, план работ, а изменения в процессе работы скорее всего не потребуются. И на выходе получится готовый продукт, по которому предлагаются корректировки и поддержка некоторое время.
Формула принятия решения: Определяем – Анализируем – Реагируем.
3. Комплексные, сложные системы (Complex)
Если проецировать систему на задачу, то речь идет о непонятной, сложной задаче, но при этом команда с подобной проблемой уже сталкивалась и имеет опыт ее решения. Например, у заказчика есть видение продукта, но мы никогда ранее этого не делали. Это может быть эксперимент или модель или работающий прототип на основе его идеи.
В жизни это может выглядеть следующим образом, заказчик пришёл с идеей о замене старой неэффективной платформы по подсчёту сельскохозяйственных животных, на новую, основанную на искусственном интеллекте, необходимо предложить решение и прототип для того, чтобы заказчик остался с нами. Чем быстрее мы сориентируемся в комплексной среде и предоставим результат, тем выше шанс оставить конкурентов позади. А в реализации прототипа и вовсе может оказаться, что сначала заказчик хотел видеть многостраничное решение, потом более лаконичное на одну страницу, а потом и вовсе может смениться руководство и выдвинуть идею подсчитывать не только животных.
Формула принятия решения: Измеряем – Определяем – Реагируем.
4. Хаотичные системы (Chaotic)
Здесь хорошо работает экспериментальный подход. Хаотичные – абсолютно новые задачи, которые никто и никогда не решал раньше. Попытка разобраться с такой системой – путь к инновациям. Любой способ решения (стабилизации системы) будет новым. Порой нужно действовать вразрез с традиционными методами менеджмента. В реальной жизни это может быть стартап или падающие стены в момент, когда вы читаете эту статью и здесь остаётся только действовать, причём как можно скорее!
Формула принятия решения: Действуем – Определяем – Реагируем.
Успели сориентироваться в какой из систем подходят именно гибкие практики управления? Ответ очевиден, даже если оттолкнуться от определения Scrum – «это лёгкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем», и поэтому его можно применить только в Комплексной, сложной системе: в остальных он будет чувствовать себя не так уверенно, или же будет совершенно бессмысленным, что принесёт большую потерю в деньгах и времени.
Фреймворк намеренно не полный, гибкий и определяет только правила, которые задают ориентиры для отношений и взаимодействий людей, что помогает быстрой адаптации, опять же, в комплексной среде.
Попробуйте спросить себя: действительно ли у меня настолько большая изменчивость, для внедрения Scrum? Если ответ отрицательный, не усложняйте, приглядитесь к другим более эффективным практикам, которые существуют для каждой из этих систем. Для упорядоченных простых подходит каскадная методология управления проектами, для упорядоченных сложных систем – подходы PMI, Prince2 и PMBoK, а в хаотичных необходимо действовать как можно скорее, чтобы выжить – поэтому подойдёт экспериментальный метод управления основанный на новых ещё не зарекомендовавших себя подходах.
Отлично, мы разобрались с системой управления и поняли, что Scrum нам всё-таки нужен. Но что дальше?
Дальше необходимо определиться с тем, кто будет нести ответственность за применение Scrum в соответствие сo Scrum Guide, и ключевая в этом плане ответственность лежит на Scrum-мастере.
Наука (Science)
Наука, это особый вид познавательной деятельности, направленный на выработку объективных, системно организованных и обоснованных знаний о мире. Говоря проще, если в мире появляется широкий интерес к некоему своду идей, которые не попадают под описание другими науками – этот свод может стать наукой. Новые науки появляются постепенно, по мере развития человечества.
Пример «свежей» науки: «Сеттлеретика» - наука, изучающая возможность «переноса» информации из нашего мозга на какой-то внешний носитель (например, нейрокомпьютер), с целью обеспечения «бессмертия» человека.
Менеджмент – это наука изучающая управление интеллектуальными и материальными ресурсами.
Является ли бережливое управление проектами (Lean) Agile-фреймворком?
Хотя Lean часто вносят в список Agile-фреймворков, это отдельная методология. Lean и Agile часто группируют вместе, потому что их ценности во многом совпадают. Например, и для Lean, и для Agile важна способность легко адаптироваться к изменениям.
- Устранение потерь
- Повышение качества
- Создание знаний
- Отсроченные обязательства
- Быстрая поставка
- Уважение к людям
- Полная оптимизация
Методология (Methodology)
Если философия показывает нам, что мы хотим учитывать в управлении проектами, то методология дает нам набор принципов и практик, руководствуясь которыми мы получаем ответ на вопрос «Как управлять проектом». Методология может иметь множество разных принципов и практик, которые можно использовать частями, в зависимости от специфики решаемых задач.
Д. Определение эпика Agile
В Agile-методологии управления проектами эпики — это «крупные истории пользователей».
История пользователя по своей сути — это то, что пользователь хотел получить. В данном случае, это результаты, которые запросил ваш клиент. В идеале история пользователя достаточно компактна, чтобы уместить ее в один спринт. Допустим, вы работаете над книгой. Если бы вы могли уложить каждую главу в отдельный спринт, то каждая глава была бы историей пользователя.
Но что если на написание каждой главы потребовалось бы восемь недель? История пользователя оказалась бы слишком большой для одного спринта и считалась бы крупной историей или эпиком.
Для эпиков нет жестких ограничений по размеру. Все зависит от длительности спринтов у вашей команды и от потребностей проекта.
Еще один важный термин — это «тема». Тема — это набор историй пользователей, которые связаны между собой или могут быть отнесены к одной категории. Например, если вы планируете строить дом, то можете сгруппировать все электротехнические требования в одной теме, а требования к качеству строительных конструкций в другой.
История, эпик и тема — это термины, которые используют многие Agile-команды, чтобы упростить обсуждение и планирование бэклога продукта. В бэклоге продукта может оказаться требование, слишком масштабное, чтобы назначить его одному спринту, но если вы обозначите его как эпик, каждый участник поймет, что его нужно разбить на части, прежде чем помещать в бэклог спринта.
Точно так же группировка требований по темам может помочь вам запланировать бэклог спринта. Ведь собранные вместе условия может быть удобно выполнить в рамках одного спринта.
Управление проектами с использованием эпиков сводится к управлению бэклогом исполняемым образом. Это гарантирует, что требования будут достаточно компактными, чтобы их можно было выполнить в период от одной до четырех недель.
- Вы можете отслеживать крупные, нечетко определенные идеи в своем бэклоге. Можно записать требование как эпик, а затем изменить его по мере выполнения проекта.
- Вы можете установить иерархию для элементов вашего бэклога. Эпик остается в бэклоге в виде оригинальной идеи или требования. Связанные с ним истории пользователей отслеживают аспекты продукта, которые позволят это требование удовлетворить.
Однако команды могут запутаться в эпиках и историях и часто прилагают слишком много усилий для их оценки, отслеживания и уточнения.
Эпики задумывались как полезный инструмент группировки в вашем бэклоге, но если они создают для вас сложности, возможно, вам лучше обойтись без них.
Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.
Как Scrum появился в вашей компании?
Последние лет 5 Scrum стал настолько популярен, что о нём не говорит разве что моя бабушка. И это логично, ведь основные причины такой популярности в том, что Scrum прост для понимания, и для его применения есть подробное Руководство (Scrum Guide), помогающее командам эффективно создавать сложные продукты с высокой ценностью и в условиях высокой неопределённости. Более того, Scrum уже давно выходит за пределы разработки программных продуктов. Сами основатели этого фреймворка в обновлённой версии Scrum Guide от ноября 2020г., признаются, что «следят за тем, как Scrum всё больше используется в постоянно растущем комплексном мире». Но есть и подводные камни –например, из-за такой популярности на этот фреймворк его часто применяют совершенно не подкованные в нём люди.
Количество не означает качество. Топ менеджеры и руководители многих компаний, не понимающие, что это, но многое слышавшие о Scrum, привлекают коучей или, что ещё хуже, пытаются внедрить принципы Agile и фреймворк Scrum самостоятельно – и зачастую впоследствии именно эти люди делают Scrum ужасную антирекламу. Не разобравшись в тонкостях и нюансах, не приняв и не осознав главные принципы Agile, не изменив свою картину мировоззрения, невозможно изменить картину мироздания своих подчинённых.
Как главный пропагандист гибких методологий я рада, что Agile захватывает мир – но маленький перфекционист внутри меня страдает от изувеченного применения фреймворка, который потом ведет к разочарованию и больше негативному опыту. Как этого избежать?
Если вы действительно хотите применить гибкие подходы к управлению, то начинать следует с изменения структуры управления в организации, меняющую среду работы людей. Только в этом случае их образ мышления будет меняться, а новые методы работы будут соответствовать их восприятию собственных действий. В пример можно взять «Сбербанк»: результатом полноценного внедрения Scrum которого стало создание глобальной структуры, обеспечивающей необходимый уровень гибкости организации. Изменяя способ выполнения работы, мы меняем и тип мышления сотрудников. Scrum не может возникнуть из неоткуда, он должен поддерживаться и внедряться в первую очередь со стороны руководства организации – а иначе он обречён.
Но стоит также помнить, что изменение среды и попытки изменения привычного образа мышления всегда болезненно воспринимается людьми. Поэтому так важно, чтобы сами сотрудники видели в изменениях ценность для себя.
Это наталкивает нас на мысль о ещё одной причине неудачного внедрения Scrum: это требует слишком больших изменений и приносит слишком много боли как сотрудникам, так и руководству. Если корпоративная культура в организации в достаточной степени соответствует принципам Agile, внедрение Scrum происходит достаточно гладко – он более осознанно воспринимается сотрудниками, создаётся необходимое напряжение и выход из зоны комфорта, который в свою очередь способствует изменению культуры и обеспечивает успешное внедрение Scrum и Agile-трансформацию организации. Но в тех случаях, когда организационная культура далека от принципов Agile, попытка внедрения Scrum чаще всего приводит к печальным результатам.
Из этого вытекает следующий вопрос: а действительно ли он вам так нужен? Чтобы понять это и выбрать верный путь управления, необходимо понять, в какой системе вы существуете.
В. Фреймворк Scrum
Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.
Как и в случае других Agile-фреймворков, Scrum использует итеративный подход к управлению проектами. Методология Scrum предписывает разбить проект на спринты длительностью от одной до четырех недель. Каждый спринт заканчивается созданием работоспособной версии черновика продукта.
Короткие итерации, свойственные методологии Scrum, позволяют команде последовательно создавать работающий конечный продукт.
Scrum изначально разрабатывался с помощью программной модели, предусматривающей набор ролей и обязанностей и регулярные совещания. Он достаточно гибок, чтобы его можно было применить в ходе любого сложного проекта в любой отрасли, но лучше всего он подходит для случаев, когда в рамках проекта создается конкретный продукт, а не оказывается услуга.
Scrum считается достаточно простым и гибким, но его трудно освоить из-за трех главных ценностей:
- Прозрачность. Необходимо использовать общий язык и стандартные определения.
- Инспекция. Артефакты и продукты должны регулярно и тщательно проверяться для обеспечения качества.
- Адаптация. Если инспекция выявит качество ниже стандартного уровня, команда обязана как можно быстрее внести корректировки или исправления.
Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:
- Владелец продукта. Владелец продукта в ходе выполнения проекта — это человек, представляющий интересы клиента. Он имеет право решающего голоса в отношении конечного продукта. Задача владельца продукта заключается в том, чтобы обеспечить понимание требований, функционала и приоритетов, а также воплотить в жизнь все эти аспекты.
- Scrum-мастер. Scrum-мастер ответственен за организацию ежедневных совещаний, улучшение взаимодействия в команде и повышение продуктивности. Разница между менеджером проектов и Scrum-мастером состоит в том, что последний стремится быть лидером-служителем. Роль менеджера Agile-проекта часто включает в себя и обязанности Scrum-мастера. Однако он может делегировать эти обязанности участнику команды, который хорошо знает Scrum и обладает организаторскими способностями.
- Команда разработки. Команда разработки — это ваша проектная группа. Обычно это самоорганизующийся и межфункциональный коллектив. Команда включает в себя всех сотрудников, необходимых для проектирования, производства, тестирования и выпуска финального продукта.
- Scrum-команда. Scrum-команда состоит из команды разработки, Scrum-мастера и владельца продукта.
Scrum также имеет собственную уникальную терминологию. Далее приведены важнейшие термины, часто используемые при работе с фреймворком Scrum:
- Бэклог продукта. Бэклог — это список задач и требований, которые должны быть выполнены применительно к конечному продукту. За создание бэклога и управление им отвечает владелец продукта.
- Спринт. Спринт — это период времени для выполнения набора задач из бэклога. Длительность спринтов должна быть одинаковой. Обычно это две недели, хотя спринт может длиться от одной до четырех недель в зависимости от потребностей команды и проекта.
- Планирование бэклога. Планирование бэклога (иногда его еще называют планированием спринта) — это определение задач в бэклоге, которые нужно включить в каждый из спринтов.
- Бэклог спринта. Часть бэклога, назначенная текущему спринту.
- Ежедневный Scrum. Проектная группа встречается каждый день, чтобы обсудить ход работ за последние сутки, ожидаемый прогресс за следующие сутки и возникающие проблемы. Обычно такие встречи называются ежедневный Scrum или стендап и длятся около 15 минут.
- Ретроспектива. Каждый спринт должен заканчиваться обзорным совещанием, которое называется ретроспектива. Команда рассматривает свои достижения и обсуждает возможности что-то улучшить в ходе следующего спринта.
- Scrum-доска. Scrum-доска помогает участникам команды видеть бэклог спринта и управлять им. Доска может быть настоящей или виртуальным инструментом в системе управления проектами. Обычно на доске есть три столбца: «К исполнению», «В работе» и «Выполнено». По мере выполнения объектов из бэклога они перемещаются по доске из одного столбца в другой. Поэтому все видят, что им нужно делать в следующем спринте и как продвигается работа.
- Артефакт. Бэклог продукта, бэклог спринта и инкремент продукта — это три артефакта Scrum в проекте. Бэклог продукта и бэклог спринта отражают работу, которую нужно сделать, а инкремент продукта — это часть продукта, которую команда создала в ходе текущего спринта.
Играете ли вы по правилам?
Вы пробовали играть в шахматы 20 фигурками вместо 32? «Зачем мне это делать,» – скажете вы, – «ведь тогда это станет совсем другой игрой с неизвестным исходом». Но, почему-то не задумываясь над этим, мы продолжаем выкидывать, как фигурки с шахматной доски, события или ценности из фреймворка Scrum.
Чтобы правильно внедрить Scrum, важно следовать чётким правилам и работать в рамках практик фреймворка. Кен Швабер в своём блоге пишет: «Scrum – это как игра в шахматы. Вы либо играете по правилам, либо не играете совсем».
Scrum не содержит лишних правил или практик. Чтобы он работал как задумано, его нужно реализовывать целостно, следуя тем правилам, что описаны в Guide. Частичное применение правил описанных в Guide, равносильно отказу от Scrum.
Уверена, найдутся те внимательные, кто скажет: «а как же гибкость?» Здесь уместно сказать, что Scrum – это фреймворк практик, связанных небольшим набором чётко определённых правил. Фреймворк, в отличии от метода, предлагает более гибкую платформу, обуславливая ряд правил, но не ограничивает применение любых других практик и подходов в зависимости от той или иной рабочей среды. Например, в Guide представлены следующие события Sprint, Sprint planning, daily scrum, sprint review, sprint retrospective, исполнение которых обязательно, но этоне ограничивает проведения любых иных событий (например, встреч Brainstorm ideas или встреч, связанных с Research и шаринга знаний на команду или команды).
Б. Что общего у Agile-фреймоворков?
Agile-методология управления проектами — это подход к управлению проектами, использующий четыре главных ценности и 12 принципов организации проектов. Agile-фреймворки разработаны для поддержки этих ценностей и принципов.
Agile-процесс отличается от остальных подходов к управлению проектами, так как нацелен на итеративную разработку, гибкость, постоянную обратную связь и убеждение, что люди важнее процессов. Поэтому Agile-фреймворки должны строиться на основе этих базовых ценностей.
Хотя у каждого фреймворка есть свои уникальные аспекты, каждый из них помогает вам следовать основам управления проектами, чтобы довести проект до победного конца. Agile-фреймворки считаются более простыми в сравнении с традиционными фреймворками, поскольку сводят к минимуму объемы правил и документации. Но каждый Agile-фреймоворк должен включать в себя все важнейшие процессы и этапы проекта.
Философии, Методологии и Фремйворки в IT-проектах.
Наиболее подходящим, под описание философии в IT-проектах безусловно можно назвать крайне популярный в наше время Agile.
Философия Agile основывается на 4-х пунктах манифеста, согласованного и написанного 17 независимыми IT-экспертами в 2001м году (Курсив = copy-paste):
Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану “То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.”
Как видим, здесь нет ни слова о том, как управлять проектами и какие практики использовать, однако здесь совершенно четко обозначено что в первую очередь учитывать при управлении проектами.
И тем не менее, Agile все кому не лень гораздо чаще называют методологией, нежели философией, а причина в том, что создатели манифеста, на той же встрече в 2001м, помимо 4 ценностей, вывели также 12 принципов Agile:
Мы следуем таким принципам:
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды. Работающий продукт — основной показатель прогресса. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Простота — искусство минимизации лишней работы — крайне необходима. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Здесь мы можем углядеть больше конкретики, которая, для внимательного менеджера может стать ответом на вопрос «как управлять», тем самым, позволяя утверждать что Agile это методология.
Вот почему возникает путаница. Мы можем использовать ценности Agile манифеста, и принципы совершенно другой методологии, и в этом не будет ничего страшного, пока наши решения идут на благо проекта. Либо наоборот, мы можем использовать принципы Agile вместе с ценностями которые исповедует наша компания, что будет означать, что мы используем корпоративные ценности как нашу философию (вопрос «что учитывать») и принципы и инструменты Agile (вопрос «как управлять») как нашу методологию.
Таким образом, ценности которыми ты руководствуешься (вопрос «что учитывать») – суть, твоя философия. В свою очередь принципы, которые указывают на то как управлять проектом – это твоя методология.
Надеюсь мы более менее уловили разницу между философией и методологией.
Примеры наиболее популярных методологий для общего ознакомления (Можете пройти по картинкам быстро, исключительно для улучшения понимания общей картины. Детали писать не буду, при желании можете легко загуглить любой из непонятных терминов.):
Lean (Бережливое производство / Бережливая разработка, часто используется и интерпретируется как философия):
Фреймворк для управления проектами — это набор инструментов, задач и процессов, используемых для организации и выполнения проекта от начала и до завершения. Фреймворк описывает все, что вам нужно для успешного планирования ваших проектов, контроля и управления ими.
Стандартный фреймворк для управления проектами можно разбить на три большие части:
- Жизненный цикл проекта. Ключевое различие между методологиями Waterfall и Agile заключается в том, что эти фреймворки включают в себя разные жизненные циклы. Например, фреймворк Waterfall состоит из пяти стандартных фаз:
- Подготовительный этап
- Планирование
- Исполнение
- Контроль
- Завершение
Фреймворк Agile скорее всего будет использовать модифицированный жизненный цикл, лучше отражающий гибкую и итеративную природу Agile-методологии.
-
Шаблоны, контрольные списки и другие инструменты. Фреймворк проекта содержит необходимую информацию для эффективного планирования проекта — от рекомендаций к задачам, действиям и ресурсам до черновой документации по проекту.
Цель фреймворка для управления проектами состоит в том, чтобы дать четкое и последовательное описание проекта, которое обеспечит надежное и повторяемое выполнение проектов разными командами и компаниями. Фреймоворки документируют и предоставляют в общий доступ лучшие рекомендации, и это выгодно всем. Также они помогают создавать единые стандарты в организациях и целых отраслях.
Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.
В чем разница между методологией и фреймворком?
Методология описывает принципы управления проектами, ценности и лучшие рекомендации, которые нужно соблюдать, в то время как фреймворк показывает способ соблюдения. Другими словами, методология объясняет вам, чего вы ходите добиться, а для фреймворка важно, как вы этого добьетесь.
Например, принципы Lean и Agile гласят, что жизненно необходимо реагировать на изменения. Но эти методологии не объясняют, как сделать так, чтобы ваши проекты хорошо реагировали на изменения — такая информация изложена во фреймворке.
Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка
Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?
Ни один фреймворк не является универсальным, так что очень важно оценить отдельные проекты и потребности команды.
Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).
- Оцените объемы проекта. Большой длительный проект может быть трудно разбить на двухнедельные спринты. Но если его размах трудно определить и он может расти, то Agile, скорее всего, лучше подойдет, чем более традиционный фреймворк.
- Определите движущие факторы проекта. Очень важно знать экономическое обоснование проекта и его ценность для организации. Какие преимущества он даст вашей компании?
- Составьте представление о ключевых целях клиента, ожидаемых результатах и приоритетах проекта.
- Выявите все факторы, цели, результаты и приоритеты проекта, на которые могут повлиять различные методологии. Например, если ваша цель — максимальная экономичность, возможно, вам подойдет бережливая методология Lean. Если клиент рассчитывает получить подробную документацию, правильным выбором может стать FDD.
- Составьте список возможных методологий, подходящих для вашего проекта, и расставьте их по порядку на основе критериев, выявленных на прошлом этапе.
- Выбирайте фреймворк, подходящий для большинства факторов, целей, результатов и приоритетов. Если какие-то результаты важнее остальных, можете расставить приоритеты, чтобы не упустить самое важное. Вам нужно выбрать фреймворк, который даст наилучший результат с наименьшим риском.
- Выбрав фреймворк, отслеживайте его эффективность. Суть всех Agile-методологий заключается в гибкости и адаптивности. Если выбранная вами методология не дает желаемого результата, следует модифицировать или даже заменить ваш фреймворк.
Нашли ли Вы своего Scrum-мастера?
Ист. Разница между хорошим Скрам Мастером и отличным Скрам Мастером
В компетенциях разработчика обычно не сомневаются: их видно на собеседовании, в кейсах, которые ему дают на решение. Но как насчёт Scrum-мастера? Он не производит конечный продукт, а предоставляет услуги по организации процесса команд, владельцу продукта и компании в целом. Поэтому оценивать его работу с точки зрения сервиса сложнее, да и результаты проявляются со временем. А время иногда слишком дорого обходится компании.
К сожалению, даже сертификация не может быть залогом успеха в выборе Scrum-мастера. Профессия Scrum-мастера находится на стыке нескольких областей познания: менеджмент, психология личности, групповая динамика, фасилитация и, конечно, фреймворк Scrum.
Что может быть показательно? Конечно, уже реализованные успешные кейсы претендента на эту роль. Но если это только начинающий специалист, их может быть недостаточно. В таком случае можно дать команде лично познакомиться со Scrum-мастером, так она точно выберет именно своего. Прекрасная статья на тему того, что должен уметь хороший Scrum-мастер и можете ли вы им стать, написана Василием Савуновым, Agile-коучем компании ScrumTrek.
Важно также помнить, что Scrum-мастер должен тщательно продумать правильный подход к внедрению Scrum в своих командах, т. к. насильственные методы не совместимы с принципами гибкого управления. Иногда это значит, что вместо попыток сделать всё как по учебнику мы последовательно приближаем структуру и правила работы команд к тем, которые прописываются в руководстве. Чтобы минимизировать ошибки начинающего Scrum-мастера, можно почитать о типичных из них в моей статье Разбор полётов-уроки и выводы начинающего Scrum-мастера.
Scrum-мастер помогает людям договариваться между собой, как на уровне организации, так и на уровне команды. Помните один из принципов Agile “люди важнее процессов и инструментов”? Всё дело в них – людях, которые могут брать на себя сложные задачи и совместно решать нетипичные проблемы; но без Scrum-мастера, без возможности договариваться Scrum останется лишь инструментом, способным сократить лишь очереди задач без улучшения продуктивности.
Если в вашей компании уже завёлся Scrum-мастер, его работу можно попробовать оценить, собрав обратную связь с его команд. С точки зрения сервиса это будет наиболее точная оценка его работы.
Примерные вопросы, которые могут вам помочь:
1. Оцените, насколько Scrum-мастер помогает команде достигать целей (0 – никак, 10 – есть ощутимая помощь)
2. Оцените полезность Scrum-церемоний (0 – трата времени, 10 – есть ощутимая польза):
a. Планирование
b. Дейли
c. Спринт ревью (демо)
d. Ретроспективы
3. Были ли конфликтные ситуации в команде?
a. Если да, как Scrum-мастер помог их разрешению? (0 – никак не помог, 10 – помог команде конструктивно решить конфликт)
4. Насколько согласны с утверждениями (0 – вообще не согласен, 10 – абсолютная правда):
a. «При общении со Scrum-мастером я чувствую, что мою позицию слышат и понимают»
b. «Scrum-мастер помогает нам справляться с возникающими сложностями»
c. «Scrum-мастер стремится сделать нашу команду лучше»
5. Ощущаете ли вы, что продуктивность команды растет?
6. (опционально) Три вещи, за которые вы могли бы поблагодарить своего Scrum-мастера
7. (опционально) Три вещи, которые Scrum-мастеру стоит улучшить
Самым сложным в работе Scrum-мастера, на мой взгляд, является изменение образа мышления не только команды, но и своего – т. к. основная его цель – делать команды более самостоятельными (самоорганизованными), то есть учить команду обходиться без него.
И последнее, наиболее важное из-за чего что-то может пойти не так – это пренебрежение практиками, прописанными в Руководстве.
Ж. Бесплатные инструменты для управления Agile-проектами
Все, что вы используете для управления Agile-проектами, является Agile-инструментом для управления проектами. Самый простой пример — это доска со стикерами, но и многие сложные цифровые инструменты также позволяют работать с Agile-фреймворками, такими как Scrum и Kanban.
Философия (Philosophy)
Если наука – основана на фактах и аксиомах, то философия, являющаяся производной науки, имеет под собой идеологический, более абстрактный стержень. Философия подразумевает систему убеждений, которые приводят к изменению нашего отношения к чему-либо. Философия, в целом показывает, чем мы по-умолчанию руководствуемся принимая решения в кооперации с внешним миром.
Если вы верите в то, что люди предпочитающие кроссовки, классической обуви, более разговорчивы и им можно доверять – это один из элементов вашей философии, так как он в какой-то мере определяет ваше отношение к людям.
Философия в управлении проектами – это свод идеологических принципов, которые отвечают на вопрос «Что мы хотим учитывать при управлении проектом». Для каждого отдельно взятого проекта мы можем очертить свою философию, которая будет соотвествовать нашим целям, и целям проекта.
Фреймворк (Framework)
Фреймворк – это по сути готовая, самодостаточная структура с заранее обозначенными правилами и практиками, придерживание которых по задумке должно привести к определенным результатам.
Фреймворк в контексте управления проектами, это проверенная, работающая схема действий, которая в чистом виде не подразумевает добавление других практик. Однако, мы можем "одолжить" нужные нам принципы и практики из уже существующих фреймворков, добавить пару своих правил, использовать все это на некоем проекте, и сказать что мы придумали фреймворк :-).
Резюмируя
Пожалуйста, не поддавайтесь моде, проанализируйте и соотносите риски с возможностями. Подумайте, в какой системе находитесь и какой стиль управления подходит именно вам.
Определились с тем, что у вас высокоизменчивая комплексная среда, отлично – вливайтесь в Agile! Но помните, что работать в направлении трансформаций должны высокомотивированные профессионалы и особенно тщательно нужно подходить к выбору Scrum-мастера. И конечно же, не поддавайтесь соблазну отменять те правила, что написаны в Руководстве. Может быть, не сразу, но постепенно внедряйте best practice в свой быт и будет вам счастье.
На свежем примере рассказывается о механике создания пользовательских историй, их строении и составе.
Общее описание ключевых технических компонентов большинства IT проектов (серверы, хостинг, базы данных, системы тестирования, мониторинга и анализа и т.д.)
Объясняется стандартный процесс кооперации клиента с компанией-исполнителем. Также показывается несколько структур IT компаний занимающихся аутсорсом.
Подведение итогов. Также рассказывается о возможных путях карьерного развития менеджера + пара советов.
Один из первых парадоксов, с которым может столкнуться начинающий проект менеджер – это попытка понять разницу между тем, что такое философия и что такое методология управления проектами. Путаница возникает из-за того, что в свое время множество разных авторов написали кучу книг (даже бестселлеров), в которых каждый излагал свое мнение насчет того, что считается философией а что методологией. Если начинающий проект менеджер вдобавок к книгам прочтет пару статей в вебе – он окончательно запутается. В этот момент, наиболее вероятно, у него потеряется интерес к этому вопросу, он выберет «что-то одно» и закроет тему, так и до конца не разобравшись. Вопрос становится еще забавнее, когда в офисах компаний, конференциях или на форумах эти же проект менеджеры начинают яро обсуждать что чем считать, всеми правдами и неправдами отстаивая то, почему «AAA» является философией, а «BBB» методологией.
Ввиду того, что нам интересна суть, давайте бегло пройдемся по этой теме.
Сперва поймем, где находятся «философии» и «методологии» по отношению друг к другу, чтобы нам было проще ориентироваться.
Г. Другие популярные Agile-методики управления проектами
Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:
1. Kanban
Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.
Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.
Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.
2. Экстремальное программирование (XP)
Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.
Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:
- Игра в планирование
- Частые небольшие релизы
- Приемочное тестирование клиентом
- Простота проектирования
- Парное программирование
- Разработка через тестирование
- Рефакторинг
- Непрерывная интеграция
- Коллективное владение кодом
- Стандарт оформления кода
- Метафора системы
- 40-часовая рабочая неделя для программистов
3. Функционально-ориентированная разработка (FDD)
Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.
Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:
- Разработка общей модели
- Составление списка необходимых функций системы
- Планирование работы над каждой функцией
- Проектирование функции
- Реализация функции
4. Метод разработки динамических систем (DSDM)
Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.
Этот фреймворк основан на восьми основных принципах:
- Фокус на потребностях бизнеса
- Своевременная поставка
- Сотрудничество
- Постоянно высокое качество
- Инкрементный подход на прочном фундаменте
- Итеративная разработка
- Постоянное и четкое взаимодействие
- Демонстрация контроля
5. Crystal
Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.
Читайте также: