Топ методов управления проектами при разработке софта Waterfall, Agile, Scrum, Kanban
Топ методов управления проектами при разработке софта: Waterfall, Agile, Scrum, Kanban и другие
В разработке софта до 1990-х годов все было предсказуемо и понятно: четкая последовательность рабочих процессов, пошаговый план, документация, тестирование, реализация конечного продукта.
Управление проектом было слишком неповоротливым, а отклонение от четкого плана грозило крушением рабочего процесса в целом.
Waterfall (каскадная модель или модель «водопада») и есть модель разработки программного обеспечения с четкой последовательностью действий, неповоротливостью в случае внешних или внутренних изменений и невозможностью «прыгнуть» в следующий этап, пока полностью не закрыт предыдущий.
Процесс разработки в Waterfall выглядит как поток процессов от этапа к этапу с четкими требованиями и условиями. Пока не завершен один этап — нет перехода к другому.
В 1990-х годах на смену неповоротливым методам пришло семейство гибких
Конечно, мы говорим об Agile (agile software development, от англ. agile — проворный) методах разработки программного обеспечения. Новый подход к методологии управления проектами ворвался в IT и позже перешел в производство, инженерию, разработку искусственного интеллекта и т.д.
Первыми гибкими методами были: RAD (с ориентиром на качество при минимальном бюджете и ограниченном сроке), XP (экстремальное программирование с коллективным владением кодом), SCRUM (где каждый участник команды несет ответственность за результат), Kanban (визуализация этапов разработки на доске) и другие.
Четыре Agile-идеи, которые важно знать:
- Люди в команде и взаимодействие между ними важнее процессов
- Взаимодействие с заказчиком важнее согласования условий договора
- Работающий продукт на первом месте. Документация — второстепенна
- Готовность быстро реагировать на изменения важнее заранее утвержденного плана
Прежде, чем мы перейдем к описанию основных конкурентов Waterfall, их преимуществам/недостаткам для разработки и управлении проектами, предлагаем сравнительную таблицу Agile и Waterfall:
Agile | Waterfall |
---|---|
Гибкость рабочих процессов и внесение изменений при первой необходимости | Каскадная модель разработки с жесткой последовательностью процессов |
Готовый продукт важнее документации | Документация важнее готового продукта |
Личная ответственность каждого участника команды за результат | Ответственность за результат в целом на команде |
Взаимодействие с заказчиком в процессе разработки | Заказчик не привлекается к рабочему процессу.![]() |
Максимальное вовлечение владельца продукта в рабочий процесс | Владелец продукта минимально задействован в рабочем процессе |
Рабочий процесс разбивается на короткие спринты. Обычно от 1 недели до 1 месяца | Каждый рабочий процесс — отдельная фаза, которая длится до тех пор, пока не проходит этап тестирования и одобрения |
Популярные системы управления проектами в Agile
Рассмотрим те, которые «прижились» и чаще всего используются в разработке софта.
Scrum
Гибкий подход к разработке софта, где одна задача — один спринт. Спринт при Скрам подходе может длиться от 1 недели до 1 месяца.
Для кого подходит Scrum?
Для небольших компаний или отделов, где владелец компании или руководитель отдела может физически «включиться» в рабочий процесс и быть его активным участником. Также этот метод идеален для стартапов.
При использовании метода Scrum в проектном менеджменте сложно найти главного или «крайнего». Ответственны за результат каждый из участников команды, а самоорганизация становится приоритетной для формирования рабочих процессов.
Команда, которая выбрала для управления проектами Scrum, должна быть готова к максимальной гибкости. То есть, если один из участников команды на некоторое время «выпал» из рабочего процесса, его обязанности по задаче или проекту должен подхватить другой.
Scrum = команда, владелец продукта и скрам-мастер, которые работают совместно и каждый отвечает лично за результат.Скрам-мастер — проектный менеджер и ключевое звено в команде. На нем: организация бизнес-процессов, собраний, мотивация команды, быстрое реагирование на изменения и решение текущих вопросов.
+ Плюсы
Софт «пилится» быстрее, включенность каждого участника команды максимальная, снижается стоимость разработки за счет разделения рабочего процесса на короткие спринты.
— Минусы
В Scrum нет жестких рамок и требований, но есть место экспериментам, меняющимся бюджетам и срокам. В работе с клиентами, для которых важен четкий план и наличие подписанного договора Scrum не подойдет.
Например: если нужно создать продукт для государственной организации, где заключение договора приоритетно — Scrum не подойдет. Здесь отчеты на предпоследнем (и даже последнем) месте. На первом: готовый продукт и только после — документация, отчеты о работе и тд.
Пример управления проектами по методу Scrum
Есть задача: создать ПО в кратчайшие сроки. Рабочий процесс делится на спринты. Каждый спринт заканчивается демонстрацией готового результата. Кроме того, в скрам-спринтах важны собрания и совещания, на которых можно подвести промежуточные итоги и переходить к следующему спринту.
Когда один спринт закончится — ту же начинается другой. Идеально, когда спринты при использовании Scrum подхода одинаковы по продолжительности.Контроль скорости завершения спринтов — важный элемент Scrum
Чтобы понимать, сколько продлится тот или другой спринт, на старте спринта участники команды могут запускать таймер. Фиксация времени, затраченного на одну задачу, даст понимание необходимого времени по следующим задачам. Достаточно заложили времени для задачи ли нет?
Kanban
Визуализация рабочего процесса и поэтапное перемещение задачи от «Принято в работу» (например) до «Готово». Между этими двумя станциями может быть еще несколько: «Разработка», «Тестирование», «Оптимизация» и т.д. Канбан визуально представляет собой доску, по которой мы перетягиваем однотипные задачи со станции на станцию. И когда задача приходит на конечную станцию «Готово» — она завершена.
Kanban — максимальная гибкость и адаптация к изменениям в любой момент.
Scrum и Kanban — гибкие подходы к управлению проектами. Но Канбан, все-таки, более гибкий и вот почему:
- Допускает внезапное поступление новых задач и «переключение» между ними.
- Коллективная ответственность за результат повышает эффективность работы.
- Незапланированные задачи попадают в бэклог. Это место хранения всех задач, которые еще не приняты в работу и не запущены по Канбан.
Визуально бэклог выглядит точно такой колонкой, как и остальные этапы рабочего процесса. Если какие-то из этапов будут завершены раньше запланированных сроков, ожидающая задача из бэклога сразу же попадает на первую станцию (этап) «Принято в работу».
- Есть место для экспериментов и неизвестности в проектах или задачах. Если в процессе работы над задачей появятся новые данные/изменения, Канбан позволяет быстро адаптироваться и продолжить работу над задачей, не нарушая в целом рабочий процесс.
+ Плюсы
В отличии от Scrum, Канбан не требует регулярных совещаний, переговоров и обсуждений спринтов. Это прилично экономит время и добавляет эффективности рабочему процессу, где визуально на доске видны все этапы и нет потребности в дополнительных обсуждениях.
Гибкость Канбана — лучшее, что можно придумать для ведения проектов с частыми изменениями исходных данных или постоянным потоком новых задач.

Еще о Kanban говорят как о подходе к управлению проектами с позиции баланса: каждый имеет свою роль и если кто-то перезагружен или наоборот — остался без задач, все это видно на доске.
— Минусы
Работать с крупными проектами по Канбан будет сложно. Для таких проектов важно смотреть промежуточный результат, разбивать рабочий процесс на короткие спринты, утверждать пошаговый план действий заранее и прописывать все в договоре. То есть, Канбан — это больше о непродолжительных проектах и коротких задачах.
Пример управления проектами по Канбан
Есть задача: снять обучающее видео для клиента. Для съемки обучающего ролика будет создан ряд однотипных задач: «Написание сценария», «Съемка», «Черновой монтаж», «Пост-обработка». Каждая из задач на Канбан доске будет отдельной колонкой.
Как правило, при использовании Канбан метода, нет жестких ограничений по времени для каждого отдельного этапа. Но команда ориентируется на среднее время работы над каждым отдельным этапом. Чем быстрее — тем выше эффективность в целом.
Канбан или Скрам? Какая система управления проектами нужна
Выше мы описали плюсы и минусы этих двух гибких методов, но еще один интересный нюанс:
Scrum на старте работы над новым продуктом даст больше контроля и управляемостиЕсли Kanban — это максимальная гибкость, то Scrum — больше о контроле и управляемости. Когда процесс отлажен и все понятно — приходит на помощь Канбан. Он идеален для работы с однотипными задачами.
Когда продукт новый и рабочие процессы только-только налаживаются — лучше использовать Scrum, чтобы в случае резкой «турбулентности» быстро среагировать, удержать контроль, внести изменения и пойти дальше с минимальными потерями.
Scrum подход к управлению проектами предусматривает более тесную коммуникацию. Это значит, что каждый участник команды сможет задать вопросы по задачам и только после полного погружения приступит к работе.
Как выбрать инструмент управления проектами?
Правильный выбор таск-менеджера — половина успеха.
Кто-то воспринимает работу в таск-менеджере — как дополнительный контроль и недоверие. Здесь важно объяснить всей команде, что таймер, например, это необходимость, а не контроль или недоверие. Таймер — это как дополнительный инструмент для улучшения эффективности работы, прозрачности процесса и результата для клиента. Кстати, таймер — это еще и возможность обосновать необходимость в оплате труда сверх нормы (если для выполнения задачи понадобилось больше времени, чем заложили в задачу изначально).
6 признаков того, что таск-менеджер выбран правильно:
- Команда максимально безболезненно перенесла все рабочие процессы в аккаунт
- Функционал интуитивно понятен и используется участниками команды
- Команда легко использует один из гибких подходов в управлении проектами: Scrum или Канбан
- Появилась систематизация рабочих процессов и увеличилась общая эффективность
- Коммуникация с командой стала более слаженной: проекты, задачи и комментарии к ним не теряются
- Клиент получает обратную связь в виде прозрачного отчета по задачам и проектам и может отслеживать рабочие процессы, если у него есть такой запрос
FAQ
Какие бывают методы управления проектами?
Каскадная (водопадная) и гибкая (итерационная) — две основные на сегодняшний день методологии управления проектами, включающие в себя набор методов. Каскадная: PERT, метод критического пути и освоенного объема, а также некоторые другие.
Итерационная («Agile Umbrella»): Scrum, Kanban, Feature Driven Development, XP (Extreme Programming), Lean, Six Sigma, PRINCE2. Ключевые принципы гибкой методологии Agile: участники проекта и коммуникация между ними приоритетнее процессов; эффективное взаимодействие с заказчиком приоритетнее, чем согласование условий договора; главное — работающий продукт, документы второстепенны; готовность к оперативному реагированию на произошедшие изменения важнее первоначального плана.
Что такое управление проектами?
Управление проектом (проектный менеджмент, Project Management) — совокупность действий, направленных на согласование участников проекта, процессов, инструментов и навыков для достижения поставленных перед проектом целей и запланированных результатов, в соответствии с выдвигаемыми требованиями.
Грамотное управление проектами помогает повысить процент успеха, прозрачность и наглядность, оптимизировать коммуникацию, и способствует оптимальному распределению имеющихся ресурсов (люди, время, финансы).
Как управлять проектами?
Наиболее эффективный и востребованный способ управления проектами — использование специфических инструментов контроля и управления. В большинстве случаев, эти инструменты представлены профильным программным обеспечением, где все необходимые функции объединены в удобном и наглядном интерфейсе. Современный рынок ПО предлагает обширный ассортимент подобных сервисов, каждый из которых обладает своими отличительными особенностями. Пользующиеся в настоящее время популярностью сервисы используют такие инструменты, как диаграмма Ганта, канбан доски и многие другие.
Каким проектам лучше всего подходит гибридная методология?
Под термином «гибридная» подразумевается такая методология, в которой сочетается все лучшее из каскадной и итерационной. Для данного подхода характерны: гибкость, структурированность и универсальность, так как он может быть применен для разнообразных проектов. Выбор в пользу гибридной методологии оптимален, если речь идет о сложном проекте среднего объема с не четкими требованиями, для которого одинаково значимы, как гибкость, так и планирование, и который имеет строго установленный бюджет.
Для чего нужно управление проектами?
Эффективное проектное управление дает возможность: грамотно управлять проектом, получить целый комплекс средств достижения стратегических целей, обеспечить выделение всех видов ресурсов (трудовых, финансовых, временных и т.д.) на решение исключительно тех задач, которые будут способствовать продвижению компании в целом к достижению ключевых целей. Благодаря внедрению методологии управления проектами достигается прозрачность, которая в сочетании с представленным контролем, обеспечивает возможность оптимизации расходов ресурсов, что способствует сокращению их объема и снижению всевозможных затрат.
Что должен делать менеджер проекта?

Что такое методология управления ИТ проектом?
Это свод правил и принципов, которых придерживаются в течение процесса работы. В сфере IT наиболее часто используется гибкая методология Agile и каскадная Waterfall. Выбор оптимальной стратегии определяется масштабами проекта, спецификой его задания, объемом выделенного времени и бюджетом.
Курс Управление проектами по Agile. Базовый курс в Екатеринбурге
1. Введение в Agile• Введение в Agile. Разработка Новых Продуктов. Итеративно-инкрементальный подход. Минимальный Продукт. Вывод на рынок и постоянное улучшение
• Краткий обзор Agile. История, 4 ценности и 12 принципов Agile
• Выгоды гибкого управления проектами и частых поставок
• Скрам – самая популярная методология, преимущества Scrum
• Общий принцип реализации проекта по Scrum — роли, мероприятия, артефакты
• Владелец продукта (продакт оунер)
• Скрам мастер
• Команда проекта
• Мотивация гибкой команды.

• Кросс-функциональность и Т-компетенции
3. Скрам – артефакты (инструменты)
• Спринт (Итерация)
• Планирование проекта и составление бэклога проекта
• Пользовательские истории
• Карта пользовательских историй (User Story Mapping)
• Расстановка приоритетов задач в бэклоге
4. Скрам – артефакты (инструменты)
• Планирование спринта, бэклог спринта
• Доска задач (Канбан доска)
• Долгосрочное и краткосрочное планирование в Scrum
• Скорость команды (Team Velocity)
• Диаграмма сгорания задач (Burndown Chart)
5. Скрам – мероприятия (коммуникации)
• Планирование спринта
• Ежедневный стендап
• Ревью спринта (демо)
• Ретроспектива
6. Управление проектами — Канбан
• Обзор Канбан метода, ценности и принципы
• Влияние количества одновременно выполняемых задач на скорость поставки результата. Закон Литтла (wip limits)
• Эффективность процесса и утилизация ресурсов
• Понятие стоимости задержки (cost of delay) и типовые классы задач (work types)
• Обзор Канбан метода, ценности и принципы
7. Практики Канбан
• Визуализируйте работу
• Ограничивайте незавершенную работу
• Управляйте работой
• Делайте правила явными
8. Инструменты Канбан метода
• Культура постоянных улучшений
• Прогнозирование эффективности, основанное на метриках и графиках
• Важность сотрудничества в Канбане
• Классы сервисов (classes of services)
9. Ключевые митинги в Канбан (каденции):
• Пополнение очереди (replenishment meeting)
• Планирование (delivery planing meeting)
• Стендап (kanban meeting)
• Анализ эффективности (service delivery review)
10. Инструменты руководителя проекта
• Программное обеспечение для ведения Agile проектов
• Вспомогательные инструменты
Финальный тест с проверочными вопросами.
Рекомендации по управлению проектами по методике Agile — Azure Boards
- Статья
- Чтение занимает 15 мин
Были ли сведения на этой странице полезными?
Да Нет
Хотите оставить дополнительный отзыв?
Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.
Отправить
Спасибо!
В этой статье
Azure Boards | Azure DevOps Server 2020
Azure Boards предлагает гибкие средства планирования, многие из которых работают в сочетании друг с другом. В этой статье представлено руководство по началу работы руководителей проектов, Azure Boards. Если вам и вашим командам требуется минимальный подход к отслеживанию для планирования проектов и управления ими, начните с этого руководством. Кроме того, при переходе от каскадного управления проектами к гибким методам Начните с этого руководства.
В этой статье мы предлагаем следующие рекомендации и рекомендации:
- Настройте команды для поддержки свертки пользовательских историй по разработке функций управления проектами.
- Определение и работа в течение спринта
- Использование пользовательских историй и функций для контроля конечных результатов
- Использование функций и невыполненных работ продуктов вашей команды для создания плана продукта
- Использование тегов для поддержки запросов и фильтрации
- Прогнозирование плана продукта, чтобы получить представление о возможностях поставок конечных результатов, задать вехи
- Управление зависимостями путем связывания рабочих элементов
- Назначение работы спринтам
- Просматривайте ход выполнения и конечные результаты, используя планы невыполненной работы, свертки и доставки компонентов.
- Пообщайтесь с улучшением процесса во время планирования и ретроспектив спринта
Настройка команд
Azure Boards предоставляет каждой команде набор гибких средств для планирования и мониторинга работы. Каждый проект определяет команду по умолчанию, которую можно сразу же приступить к использованию. тем не менее, если у вас есть несколько групп разработчиков или функций, рекомендуется определить группу в Azure DevOps для каждой специализированной группы. Таким образом, каждая команда может работать автономно при совместной работе друг с другом.
Советы и рекомендации:
- Настройка команд в потоках значений, которые ваша организация хочет доставлять
- Определите группу для каждой группы разработчиков от шести до двенадцати разработчиков
- Настройка групп разработки для поддержки свертки в группы функций управления проектами
Чтобы узнать, как это делать:
Настройка спринтов
Спринты, определяемые путями итерации, определяются для проекта, а затем выбираются группами. Интервал спринта может меняться в пределах одной недели до четырех недель или больше. Кроме того, можно определить спринты в иерархии, включающей в себя обучение выпусков. Вы назначаете рабочие спринты, которые команды фиксируют для доставки в конце спринта. эти Azure Boards средства полагаются на назначения спринтов для невыполненной работы спринта, Taskboard, прогнозирования и планов поставок.
Советы и рекомендации:
- Определение периодичности спринта, которую будут использовать все команды в группе продуктов
- Определите не менее шести итераций, которые будут поддерживать планирование для следующих шести – двенадцати месяцев
- Определение того, как команды будут использовать итерации для управления элементами невыполненной работы
- Неназначенная работа по спринту назначается невыполненной работе по умолчанию или
- Неназначенная работа по спринту назначается назначенному будущему спринту невыполненной работы.
Чтобы узнать, как это делать:
Выбор типов рабочих элементов, которые будут использоваться
Определите типы рабочих элементов, которые ваша команда будет использовать для сбора требований клиентов и разработки. Если проект основан на гибком процессе, мы рекомендуем использовать пользовательские истории, ошибки и функции.
Примечание
Рекомендации, приведенные в этой статье, основаны на гибком процессе.
Если проект основан на другом процессе, таком как базовый, Scrum или CMMI, вы можете выбрать один из вариантов, показанных на следующих изображениях. Кроме того, каждая команда может определить, как они хотят контролировать ошибки.
На следующем рисунке показана иерархия рабочих элементов невыполненной работы процесса Agile. Пользовательские истории и задачи используются для наблюдения за работой, дефектами кода с ошибками, а ситуаций и функциями используются для группирования работы в более крупных сценариях.
Каждая команда может настроить способ управления ошибками (на том же уровне, что и пользовательские истории или задачи), настроив параметр Работа с ошибками . Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе Agile Process.
На следующем рисунке показана базовая иерархия рабочих элементов невыполненной работы процесса. Проблемы и задачи используются для наблюдения за работой, тогда как ситуаций используются для группирования работы в более крупных сценариях. базовый процесс доступен для Azure DevOps Server 2019 с обновлением 1 и более поздних версий.
Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе планирование и мониторинг работы.
На следующем рисунке показана иерархия рабочих элементов невыполненной работы Scrum Process. Элементы и задачи невыполненной работы по продукту используются для наблюдения за работой, дефектами кода с ошибками, а ситуаций и функциями используются для группирования работы в более крупных сценариях.
Каждая команда может настроить способ управления ошибками (на том же уровне, что и элементы невыполненной работы по продукту или задачи), настроив параметр Работа с ошибками . Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе Scrum Process.
На следующем рисунке показана иерархия рабочих элементов CMMI Process невыполненной работы. Требования и задачи используются для наблюдения за работой, дефектами кода с ошибками, а ситуаций и функциями используются для группирования работы в более крупных сценариях.
Каждая команда может настроить способ управления ошибками (на том же уровне, что и требования или задачи), настроив параметр Работа с ошибками . Дополнительные сведения об использовании этих типов рабочих элементов см. в разделе CMMI Process.
Примечание
Требования определяют ожидания пользователей программного продукта. в Azure Boards требования определяются рабочими элементами, которые отображаются в невыполненной работе по продукту. Они соответствуют пользовательским историям (Agile), элементам невыполненной работы по продукту (Scrum), проблемам (Basic) или требованиям (CMMI) на основе процесса, выбранного для проекта. Они также относятся к категории требований, которая управляет тем, какие типы рабочих элементов отображаются в невыполненной работе по продукту.
Советы и рекомендации:
- Используйте функции для сбора функций клиентов, которые вы хотите поставлять
- Быстро добавляйте компоненты или требования из невыполненной работы и заполните сведения позже.
- Требованияк использованию — пользовательские истории (Agile), проблемы (основные) элементы невыполненной работы по продукту (Scrum) или требования (CMMI) — для разбиения функций на работу, которую будет владеть команда разработчиков
- Использование ошибок для записи дефектов кода
- Сопоставьте требования с функциями для отслеживания хода выполнения на уровне управления проектом
- Требования к размеру, которые должны быть выполнены в рамках спринта
- Функции размера, которые должны быть выполнены в рамках спринта или в нескольких спринтах
- Размер ситуаций, доставляемый ежеквартально или на определенную цель вехи
- Позвольте разработчикам использовать задачи для разбиения работы по мере необходимости.
Руководители проектов управляют функциями, и группа разработчиков управляет требованиями. Сопоставляя их с помощью ссылок типа «родители-потомки», вы получаете представление о ходе выполнения функций. Каждый рабочий элемент, добавляемый в невыполненную работу команды, автоматически назначает путь к области по умолчанию и путь итерации, заданный для команды.
Если у вас больше программных инициатив или сценариев, требующих доставки нескольких функций, вы можете сгруппировать их в ситуаций, снова используя ссылки «родители-потомки».
Чтобы узнать, как это делать:
Создание плана продукта
Создайте план продукта с помощью невыполненной работы компонентов. Затем команда разработчиков создает план продукта с помощью невыполненной работы по продукту. Периодически требуется просматривать и очищать планы продукта.
Невыполненная работа компонентов
руководители Project инициируют план продукта, добавляя функции в невыполненную работу компонентов. Каждая функция должна представлять поставляемую доставку, которая решает потребности клиента.
Невыполненная работа по продукту
Группы разработки добавляют пользовательские истории в свои невыполненные работы по продукту, чтобы пользовательская история автоматически назначила путь к области по умолчанию и путь итерации для группы. Затем они могут сопоставлять эти истории в каждой функции, представляющей работу, которую они делают для реализации этой функции. Каждая пользовательская история должна иметь размер, чтобы их можно было завершить в рамках спринта.
Очистка каждой невыполненной работы
Периодически проверяйте каждую невыполненную работу для выполнения следующих задач:
- Определение выполняемых работ
- Переупорядочение рабочих элементов с помощью перетаскивания, чтобы они отображались в порядке приоритета
- Открытие рабочих элементов и Добавление сведений
- Назначение работы членам команды или спринтам
- Запишите технические обязательства и не применяйте функции, необходимые для поддержки работоспособной экосистемы доставки.
- Сопоставьте неродительскую работу с компонентом, к которому они относятся
- Используемых Оценка размера требований, помогающих определить скорость работы команды и прогнозирование поддержки
Совет
Скорость работы команды можно отслеживать на основе оценок, назначенных завершенной работе, или простого количества рабочих элементов, выполненных во время спринтов. Однако для использования функции прогнозирования необходимо присвоить значение полю «баллы истории», «трудозатраты» или «размер». Если вы не хотите оценивать требования, можно просто назначить значение 1 для оценки требований, а затем использовать средство прогнозирования на основе количества рабочих элементов.
Советы и рекомендации:
- Периодическое уточнение невыполненной работы
- Убедитесь, что размеры компонентов и требований соответствуют требованиям.
- Определение критериев приемки и определения функций и действий
- Сопоставление несопоставленных рабочих возможностей с компонентами
- Прогнозирование невыполненной работы
Чтобы узнать, как это делать:
С помощью тегов рабочих элементов члены команды могут назначать нерегламентированные Теги рабочим элементам. Эти теги можно использовать для фильтрации невыполненной работы и системных плат, а также запросов к рабочим элементам. Чтобы теги были полезны команде, предоставьте некоторые общие рекомендации по использованию тегов в команде. Рассмотрите возможность документирования этих рекомендаций в центральном месте, например на вики-сайте проекта.
На следующем рисунке показана плата канбана, отфильтрованная по ключевому слову Web , которая отображает карточки с веб- тегом.
Советы и рекомендации:
- Поставьте политику того, как ваши команды будут использовать теги.
- Укажите, как вы будете использовать теги для поддержки запросов, фильтрации, создания отчетов
- Рассмотрите возможность использования тегов для обнаружения межпроектных зависимостей или зависимости между проектами.
Чтобы узнать, как это делать:
Планирование прогнозов и вех
Чтобы получить представление о возможностях, которые могут поставляться при использовании, используйте средство прогнозирования . Это средство требует предоставления оценок для полей «баллы», «трудозатраты» и «размер» для каждого требования. Если вы хотите прогнозировать по простому количеству рабочих элементов, просто назначьте значение 1 для оценки требований.
Упорядочивание невыполненной работы компонентов в порядке приоритета
Руководители проектов должны всегда иметь возможность использовать все возможности в порядке приоритета. Это дает команде разработчиков, какие функции наиболее важны для выполнения первыми.
В списке невыполненной работы содержатся сведения о последовательности функций для попоставки.
Заказ невыполненной работы по требованиям на основе родительских компонентов
Прежде всего необходимо убедиться в выполнении требований, необходимых для поставки компонентов. Как показано на следующем рисунке, невыполненная работа по требованиям была упорядочена в соответствии с функциями, которые вы хотите поставлять. В этом порядке предполагается, что все требования в компоненте должны быть завершены для последующей отправки. Кроме того, баллы истории были назначены каждой пользовательской истории.
Прогнозирование невыполненной работы по требованиям
С оценками, назначенными каждому требованию, можно задать скорость команды. В приведенном ниже примере мы указываем 12 для скорости, что эквивалентно тому, что в среднем группа может завершить 12 баллов истории за спринт. Средство прогнозирования показывает требования и функции, которые команда может выполнить в течение следующих шести спринтов. С помощью средства планирования можно быстро назначить требования прогнозируемым спринтам.
Чтобы просмотреть полное изображение, щелкните изображение, чтобы развернуть его. Щелкните значок Закрыть, чтобы закрыть окно.
Хорошие оценки и наличие предсказуемых командных скоростей являются полезными целями группы для улучшения процесса.
Обновите доску функций
Благодаря прогнозу, когда компонент будет поставляться, можно обновить путь итерации каждого компонента. Быстро назначьте значения функции, добавив эти поля в карточку на доске Канбан, как показано на следующем рисунке.
Планирование вех
маркеры вех не используются в Azure Boards отслеживания работы, за исключением планов доставки. Планы доставки предоставляют представление календаря и позволяют определить маркер вехи.
Однако можно использовать один или несколько следующих параметров, чтобы пометить рабочий элемент как веху.
Управление зависимостями
в Microsoft Project вы управляете задачами, зависящими от завершения других задач, путем их связывания. для управления зависимостями в Azure Boards можно добавить подобную связь, добавив к рабочим элементам тип связи предшественника/последователя. Эти ссылки добавляются из диалогового окна Добавление ссылки для рабочего элемента.
Диалоговое окно добавления ссылки
Azure Boards поддерживает несколько типов ссылок для отслеживания связанной работы. Выберите типы связей предшественника/последователя, чтобы отследить работу с зависимостями. Самый быстрый способ добавить ряд этих ссылок — Добавить тег к рабочим элементам, участвующим в создании или использовании зависимостей, создать запрос на основе этого тега, а затем добавить необходимые ссылки из режима рассмотрения результатов запроса.
В следующем диалоговом окне Добавление ссылки показано, как два рабочих элемента связаны с помощью типа ссылки-последователя.
Визуализация связей рабочих элементов
Можно просматривать зависимости и выявление зависимостей, имеющих проблемы с планами доставки. Как показано на следующем рисунке, можно переключать отображение линий зависимостей между связанными рабочими элементами. Дополнительные сведения см. в статье об отслеживании зависимостей с помощью планов доставки.
С помощью расширения Marketplace для визуализации рабочих элементов можно визуализировать ссылочные отношения между несколькими рабочими элементами, как показано на следующем рисунке.
Чтобы просмотреть полное изображение, щелкните изображение, чтобы развернуть его. Щелкните значок Закрыть, чтобы закрыть окно.
Минимальный допустимый или критический способ управления продуктом
Azure Boards не предоставляет собственное представление критического пути. В частности, в качестве гибких методологий лучше всего подходит минимальный приемлемый продукт (MVP) по сравнению с управлением критическим путем (КПМ). С помощью MVP вы определяете кратчайшие пути и зависимости, определяя приоритеты ситуаций, функций, историй и задач. Дополнительные сведения см. в разделе критический путь в проектах Agile и Запуск экономичного запуска на Azure DevOps.
Советы и рекомендации:
- Добавление
dependency
тега в рабочие элементы, участвующие в управлении зависимостями - Использование типов связей » предшественник/последовательный » для мониторинга зависимостей работы, принадлежащих другим командам или в других проектах
- Создание запросов для трассировки, добавления и рассмотрения зависимостей
- Используйте расширение Marketplace Tracker зависимостей для просмотра работы, от которой зависит работа других команд.
- Использование расширения Marketplace для визуализации рабочих элементов для визуализации зависимостей
Примечание
расширения Marketplace не поддерживают функции Azure Boards и поэтому не поддерживаются группой разработчиков. С вопросами, предложениями или проблемами, возникающими у вас при использовании этих расширений, обращайтесь на страницу соответствующего расширения.
Чтобы узнать, как это делать:
Работа в спринтах
Спринты позволяют команде разработчиков сосредоточиться на завершении предварительно выбранного набора действий. Работа, назначенная спринту, отображается в невыполненной работе команды спринта. Невыполненные работы спринта определяются только для невыполненной работы по продукту, а не для невыполненной работы портфеля.
Диаграмма сгорания для спринта
Обновив состояние работы ежедневно в рамках спринта, можно легко отслеживать ход выполнения спринта с помощью диаграммы «выработка спринта», как показано на следующем рисунке.
Советы и рекомендации
Каждый спринт выполняет следующие задачи:
- Планирование каждого спринта в команде
- Использование невыполненной работы спринта команды для просмотра результатов спринта
- Убедитесь, что каждый рабочий элемент спринта назначен участнику команды.
- Убедитесь, что для каждого рабочего элемента выполнена область в рамках спринта.
- Убедитесь, что критерии приемки для работы хорошо определены и понятны.
- Обновление состояния рабочих элементов спринта по мере перемещения работ с нового на активное состояние для отслеживания выполнения спринта
- Возврат с помощью других команд на зависимости, от которых зависит работа вашей команды
- Мониторинг хода выполнения спринта с помощью диаграммы «выработка спринта»
Чтобы узнать, как это делать:
Ознакомьтесь с результатами хода выполнения и функций
Ниже приведены три основных средства, которые необходимо использовать для проверки хода выполнения и конечных результатов.
- Доска канбана компонентов
- Невыполненная работа функций с столбцами свертки
- Планы выполнения
Доска канбана компонентов
Доска функций — это еще одно место для проверки хода выполнения и обеспечения непрерывного потока конечных результатов. На следующем рисунке показана настроенная доска возможностей. Добавлены столбцы «выполняется», такие как требуется дополнительная информация, Спецификация завершена, выполняетсяи развертывание клиента. Они предоставляют более естественный набор состояний по мере предложения, поиска, разработки и развертывания в рабочей среде.
Чтобы просмотреть полное изображение, щелкните изображение, чтобы развернуть его. Щелкните значок Закрыть, чтобы закрыть окно.
Свертка
Один быстрый и визуальный способ отслеживать ход выполнения — из невыполненной работы компонентов. Добавив столбец индикатора выполнения свертки, можно увидеть, какой процент рабочих элементов выполнен для каждого компонента, как показано на следующем рисунке.
Планы доставки и несколько конечных результатов команды
Для просмотра функций, доставляемых в нескольких командах, настройте план доставки. Планы доставки предоставляют интерактивную доску для просмотра календарного расписания историй или несколько команд, которые планируется доставлять.
Советы и рекомендации
- Настройка доски Канбан для поддержки процессов команды
- Добавление полей в карточки, чтобы можно было быстро и легко обновлять их значения
- Обновление пути итерации (спринта) функций, когда вы получаете ясность в момент поставки
- Просмотрите доску функций, чтобы обсудить состояние, блоки, проблемы, риски, изменения и состояние обновления.
- Используйте функцию фильтра, чтобы сосредоточиться на элементах с тегами, назначенных функциями, конкретным спринтом и т. д.
- Добавление столбцов свертки в список невыполненной работы компонента для мониторинга общего хода выполнения на основе выполнения количества рабочих элементов
- Использование планов доставки для просмотра функций, доставляемых несколькими командами, и обсуждения зависимостей между группами.
Чтобы узнать, как это делать:
Улучшение процесса
В основе методов Agile лежит постоянное улучшение. Чтобы улучшить процессы, необходимо иметь общие цели и общий план. Чтобы инициировать действия по улучшению процесса, рассмотрите возможность их добавления с помощью обычных методов, например:
- Планирование спринтов
- Настройка целей спринта
- Проведение регулярных ретроспектив
При настройке целей следует учитывать следующие вопросы.
- Что вы изучаете о клиентах? Что необходимо знать?
- Какие данные измеряются? Является ли это действие недоступным? Какие данные необходимо измерять?
- Как работает поток конечных результатов? Это так, как ожидалось? Где можно вносить улучшения?
- Ваши сотрудники вашей команды могут сделать их лучше? Какие средства или сведения помогут улучшить их работу?
- Насколько хорошо Общая информация? Насколько хорошо работают команды совместной работы?
- Насколько хорошо ваша группа управляет технической задолженностью и закрытием ошибок?
Некоторые из гибких средств, которые можно использовать для улучшения процесса, — это скорость работы команды, панели мониторинга группы и расширение Marketplace.
Скорость команды
С помощью диаграммы скорости команды можно получить представление о том, насколько хорошо группа планирует и исполняет спринт. Как показано в следующем примере, на диаграмме скорости показано запланированное, завершенное, завершенное позднее и неполное количество рабочих элементов для нескольких спринтов. Teams может просматривать эту диаграмму, чтобы определить, насколько хорошо они оцениваются и выполняются, и как они могут улучшиться.
Командные панели мониторинга
Teams может определить одну или несколько панелей мониторинга для совместного использования информации и отслеживания хода выполнения работы в режиме реального времени.
Советы и рекомендации
- Определение целей совершенствования процесса, которые ваша команда может принять, записать их и периодически проверять.
- Использование панелей мониторинга команд для обмена информацией и диаграммами отслеживания работы, которые периодически и ваша команда проводит проверку
- На совещаниях по планированию спринта ваша команда должна выявление по крайней мере одной цели спринта, связанной с улучшением процесса.
- Выполняйте обычные ретроспективные совещания для сбора данных, что не так хорошо, а также действий по улучшению
- Обслуживайте доску отслеживания улучшения, например, доступную с расширением Marketplace.
Чтобы узнать, как это делать:
Возможные дальнейшие действия
Похожие статьи
Отраслевые статьи
Планирование и управление задачами в Agile-досках
В любой компании нужен удобный инструмент для планирования и эффективного взаимодействия в команде. Сотрудники ежедневно пользуются различными способами для организации и распределения работ: от электронных сервисов до привычных бумажных планировщиков. Если основные бизнес-процессы ведутся в системе Directum RX, требуется время, чтобы отразить текущее состояние работ в системе или проконтролировать ход их выполнения.
Решение «Agile-доски» позволяет планировать и отслеживать статус работ в едином пространстве системы Directum RX.
Виртуальная доска помогает:
- наглядно отображать процесс работы по проекту или индивидуальному плану сотрудника;
- детализировать план работ: задавать приоритет, трудоемкость, исполнителей и сроки;
- оперативно узнавать о текущем состоянии работ и отражать их изменения;
- сохранять полезную информацию, историю изменений и обсуждения в одном месте.
Работа с решением
Сотрудник создает доску и распределяет работы удобным ему способом:
- для быстрого старта можно использовать колонки по умолчанию: «Новые», «В работе» и «Выполнено»;
- для детализации распределения — создавать дополнительные колонки по видам работ или сотрудникам;
- для сохранения информации — вести архив выполненных работ.
Детали работ задаются в тикете, обозначенном цветной меткой для визуального распределения задач по потокам или сферам деятельности. Сотрудники добавляют в тикет полезные ссылки на задачи, документы или папки, чтобы их было проще найти. Исполнитель может поменять первоначально заданные характеристики работ. Кроме того, за тикет можно проголосовать или обсудить детали задачи в комментариях.
ТикетРуководителю проекта или лидеру команды легко контролировать ход работ: ему достаточно в один клик отправить тикет задачей.
Задача из тикетаСотрудник может быстро найти тикеты, где он указан автором или исполнителем. Они отображаются в одном списке, даже если добавлены на несколько досок.
Бизнес-эффект
Дополняя функциональность системы Directum RX лучшими практиками по гибкому управлению и планированию работ, решение позволяет:
- сохранить прозрачность процессов по планированию, взаимодействию и контролю за состоянием работ;
- обеспечить удобный и быстрый доступ к информации, полезной для работы команды или отдельного сотрудника.
Планируйте работы с решением «Agile-доски» отдельно или в связке с модулем «Проекты» и решением «Планирование проектов».
Agile Управление проектами | Важные аспекты и принципы гибкого проекта
Что такое гибкое управление проектами?
Agile Project Management — это описательный метод управления развитием проекта с использованием определенных методов и подходов. Для постоянного улучшения проекта существуют определенные инструменты, методы и принципы. Используя эти методологии, вы продвигаетесь в проекте более эффективно.
Понимание гибкого управления проектами
Ранее, когда проект начинается, разработчик занимается разработкой программного обеспечения с использованием кода, отлаживает его всякий раз, когда он ошибается, исправляет его и все, что сделано. Разработанный код эффективно подходит для клиента или нет, вопрос. Создание небольшого фрагмента проекта казалось немного сложным. Как и когда сложность проекта увеличивается, так и трудности в процессе разработки программного обеспечения. Именно тогда появились модели разработки программного обеспечения. Для каждого цикла разработки было обучение из предыдущих итераций. Так возник термин Agile с 2001 года.
Важные аспекты гибкого управления проектами
Чтобы создать значимую итерацию, запрашивая циклы разработки программного обеспечения. 4 основных момента обеспечили большую прозрачность проектного подхода к успеху.
- Командное взаимодействие.
В процессе разработки программного обеспечения, а не только в процессе рассказа и процессов, существует необходимость в групповом взаимодействии. Именно тогда проект может привести к успеху очень эффективным способом.
- Упрощенный подход: гибкая методология основана на работе с блоками, называемыми «спринтами». Это приводит к упрощенному подходу к дальнейшему развитию.
- Сотрудничество с клиентами. Участие клиента в проекте играет очень важную роль в управлении Agile, поэтому проект ориентирован на клиента.
- Реагируйте на немедленные изменения: если есть какие-либо изменения, сделанные на любом из этапов разработки. Немедленные изменения могут быть реализованы в Agile.
12 принципов гибкого манифеста
12 принципов Agile Manifesto заключаются в следующем:
- Первый принцип — подход, ориентированный на клиента, и его обновление.
- Вносить изменения всякий раз, когда и где требуется, даже в конце стадии разработки для любых конкурентных изменений.
- Своевременная доставка программного обеспечения клиентам с большей гибкостью.
- Сотрудничество между бизнесом и командами разработчиков.
- Поддерживать и мотивировать члена команды, проявляющего интерес к проекту. Дайте им ту дополнительную работу, которую они хотели бы сделать, и доверьте им выполнение этой работы.
- Имейте личную интеграцию с командой.
- Рабочее программное обеспечение является основной мерой прогресса.
- Гибкие процессы способствуют устойчивому развитию для всех.
- Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
- Простота гибкой среды.
- Лучшие практики поступают от самоорганизующихся команд.
- Эффективно работать внутри и кросс-функциональных команд.
Agile Practices
Agile проекты основаны на общей приверженности ценностям, принципам и практикам, которые определяют Agile методологию, давайте рассмотрим несколько Agile практик, как описано ниже.
1. Гибкое планирование
Это начальная стадия любого Agile проекта. Планирование — это, как правило, первые несколько недель, когда команда решает планы работы в зависимости от времени, стоимости и доставки. Он включает в себя всех членов команды для работы в соответствии с направлением проекта от начала до выпуска.
Это планирование выполняется на 3 уровнях:
а. План релиза: владелец продукта участвует в этом этапе, когда должен происходить релиз проекта на каждом этапе.
б. План итерации: на каждой итерации члены команды планируют и работают вместе.
с. Ежедневный план: Каждый день проводится обсуждение проекта и встреча планов для отслеживания хода выполнения проекта.
2. Тестирование в Agile
На каждом этапе разработки проекта проводится тестирование. Гибкая команда разработчиков также участвует в тестировании. Что происходит двумя способами:
а) Ручное тестирование
Тестирование во время разработки — это ручное тестирование, на этом этапе разработчик напишет фрагмент кода для тестирования для проверки. Он проверяет как провал, так и тест на прохождение. Так что по частям код генерируется и тестируется до того, как будет написан следующий набор кода. Это метод тестирования от низкого до высокого. Это лучший подход.
б) Автоматизированное тестирование
Автоматическое тестирование выполняется, когда весь код написан, а затем запускает несколько тестов во всем коде, чтобы проверить наличие ошибок. Если ошибка найдена, разработчик должен вернуться к коду ошибки и исправить его. Но это кажется утомительным, потому что если часть кода изменяется, связанный с ним связанный код должен быть изменен соответствующим образом. Это высокий или низкий уровень тестирования. Следовательно, это не очень выполнимо. Вместо этого, написание фрагмента кода и его автоматическое тестирование сэкономит много времени.
3. Что нужно помнить в Agile
а) Неправильное планирование
Планирование — это первый шаг в Agile, без правильного гибкого планирования мы не можем ничего достичь.
Управление гибкой командой вместе с деловыми партнерами, операциями, управлением продуктами, управлением персоналом может быть аккуратно включено в гибкий процесс. Слишком быстрое продвижение в этом процессе может привести к пропуску нескольких важных этапов, включая сотрудничество с клиентами.
б) гибкие знания
Правильное знание / обучение дается разработчикам в Agile. Использование стратегий для документации на каждом этапе.
Agile — лучший подход к командам разработчиков, ориентированным на клиентов для быстрого развития.
Рекомендуемые статьи
Это руководство по гибкому управлению проектами. Здесь мы обсудили важные аспекты, принципы и практики гибкого управления проектами. Вы также можете посмотреть следующие статьи, чтобы узнать больше —
- Гибкая модель для разработчиков и тестеров
- Область управленческого учета
- Agile Design и его важность
- Введение в основы Scrum
Внедрение Agile в Data Science и Computer Vision проекте.

В этой статье я расскажу о своем опыте внедрения Agile на DS проекте с нуля. Я расскажу по шагам что мы с командой пробовали использовать, к чему это привело, какие ошибки допускали и как мы в итоге пришли к стабильному, простому и понятному процессу разработки.
Контекст проекта и немного введения
Проект, с которым мне пришлось работать связан с определением объектов по камерам наблюдения на физических объектах (ресторанах). Нашей основной задачей было создание системы определения объектов и вывода необходимой информации на дашборде, а также мы осуществляли развертывание системы на объектах (более 1500) и поддержку пользователей.
Наша команда состояла из Data Science и Computer Vision специалистов, было несколько QA, один Frontend Developer и один Backend Developer. Я выступал в роли Project Manager.
Когда я только приступил к работе над проектом, там не было никакой документации, плана, отчетности и т.д. Все делалось на словах, что-то немного трекалось в Trello, это был тот еще хаос.
В этой статье я расскажу больше о процессе разработки. На проекте также был очень сложный процесс развертывания и поддержки пользователей. Этих процессов касаться в этой статье я не буду.
Этап 1. Начало внедрения Agile
В самом начале моей основной целью было понять что вообще необходимо сделать, к какому сроку, кто чем занимается и что вообще есть сейчас.
В интернете я наткнулся на целую кучу различных статей о том, как выстраивать процессы в DS, но у всех были разные мнения: кто-то советовал Kanban, кто-то Scrum, кто-то описывал свои методики, но ничего общего я не нашел, не было ничего, что можно применить к любому проекту такого рода. Однако, самым ценным было знакомство с концепцией CRISP-DM
CRISP-DM.Концепция легко гуглится, но основная мысль понятна из графикеской схемы:
Как вы видите, из-за возможности возврата к предыдущим этапам, а также по причине того, что итоговый результат может оказаться все еще недостаточно хорошим мы не можем выдать заказчику точных сроков, что делает крайне сложным какое-либо планирование.
Вот какие задачи я поставил себе на самом первом этапе:
Определение всех требований к проекту
Определение текущего результата
Постановка конкретных задач команде
Оценка задач и формирование плана
Выбор процесса разработки
Вот что конкретно было предпринято на первом этапе:
Мы начали использовать Jira. Пришлось обучать команду, так как никто не работал ранее с этой системой
Мы создали Kanban доску со стандартными этапами, как To Do, In Progress, Test, Done
Я описал все требования команде и совместно с командой мы поставили первые задачи, сформировали бэклог продукта. Пришлось все уточнять у команды, так как было совершенно не понятно что уже реализовано и как конкретно реализуется то или иное требование инструментами DS и CV
Оценили с командой задачи в днях и согласовали со стейкхолдерами дедлайны
Сделали совместные чаты и т.
д., чтобы коммуникация наконец-то было централизована.
Начали проводить общие митинги каждый понедельник и синхронизироваться.
Все же решили попробовать использование Scrum, после чего я отправился настраивать доску и подготавливать тренинг для команды.
С какими основными проблемами мы столкнулись:
Постановка задачи в виде User Story или просто описания бизнес-требования плохо понятна команде, вызывает неправильные ожидания у заказчика и внутри задачи было сложно учесть какую-то смежную работу, как сбор и разметка данных и т.д.
Команда очень слабо работала с Jira. Всегда приходилось двигать таски и актуализировать доску насильственно…
Цикл выполнения задачи был очень большой из-за очень общей задачи и мог занимать до 3 месяцев
Спустя месяц работы над задачей команда могла понять, что не успеет в сроки, так как модель плохо обучена или данные были не те и т.д. и всегда приходилось сильно двигать сроки, так как еще одна итерация могла занимать до 2 месяцев
Деплой проекта на объекты был крайне хаотичен, делался по требованию и постоянно возникали проблемы
Мы проанализировали эти проблемы и решили попробовать Scrum (как ни странно, тогда это звучало логично)
Этап 2.

Перед тем, как начать разработку по Scrum, я внимательно пересобрал общий бэклог проекта, описал его в формате обычных Tasks и User story, приоритизировал его.
На самом старте в нашей Scrum доске были все те же колонки To Do, In Progress, Test, Done
Мы с командой провели первый планинг в ходе которого обсудили бэклог и еще раз проговорили принцип работы по Scrum. В ходе планирования у нас получилось следующее:
Обсудили процесс CI/CD и решили добавить UAT окружение.
Добавили соответствующий статус на доске — UAT
Оценили задачи в story points
Поставили задач на спринт
Проговорили правила работы и ответственность
После завершения нескольких спринтов оказалось, что мы каждый спринт закрываем совершенно разное количество SP: 26, 62, 28 (например)
После очередной ретроспективы мы решили начать разбивать текущие задачи на гораздо более мелкие, так как многие задачи требовали более 2 недель на полноценное решение.
После этого мы провели еще спринта 3. Мы пытались формулировать эти задачи иначе, разбивать на связанные задачи и т.д.
В результате нам удалось добиться какой-то стабильности, но выполненные задачи не несли какой-то конечной ценности и в результате спринта мы не получали релиз, мы получали просто набор выполненных задач.
Мы решили предпринять еще одну попытку и просто увеличить продолжительность спринта до 1 месяца, но ситуация изменилась не сильно + начали приходить срочные задачи, которые не могли ждать 1 месяц и нам приходилось нарушать наш план.
И мы собрались для полноценного анализа ситуации в ожидании найти какое-то радикальное решение, которое нам поможет.
Мы увидели, что нам невозможно в принципе закрывать задачи спринтами, так как работа над, например, новой моделью для определения факта оплаты клиентом может занять до 3 месяцев, при этом потом нам все равно придется вернуться к этой задаче, переобучить модель и т.д. Запихнуть это в спринт невозможно.
В результате мы решили перейти к Kanban и попробовать эту практику
3. Kanban
Итак, Канбан! За основу построения процесса разработки мы взяли LeanDS
Ссылку на книгу вы можете найти в интернете.
Я сделал новую доску и указал там следующие этапы:
To Do, Analysis, Data Preparing, Experimenting, Development, Ready for Evaluation, Evaluation, PR review, Trial, Done
Я установил на каждом этапе ограничения (WIS), которые указал в соответствии с количеством членов команды, задействованных на том или ином этапе
Также я пересмотрел бэклог и разбил работу над моделями на гипотезы, другие задачи остались по прежнему в User stories. Бэклог еще раз приоритезировали.
Пример Гипотезы:
Мы полагаем, что решим проблему появления машин-призраков на всех объектах. Для этого мы будем определять местонахождение каждой реальной машины в текущий момент времени. Мы окажемся правы, если в ситуациях, вызывающих появление гост каров сейчас, они не будут появляться и если количество обращений с ресторанов об этой проблеме снизится хотя бы на 50%
После всех приготовлений мы с командой провели Kanban планирование и договорились работать в соответствии с правилами и идеологией Kanban. Выбрали первые задачи и начали работу
Результат колоссально отличался от того, что было раньше и это стало выглядеть многообещающе:
Мы могли брать супер срочные задачи и выполнять сразу же
Мы сразу смогли увидеть на каком этапе у нас застревают задачи
Мы стали понимать как лучше распределить ресурсы
Задачи стали активнее переходить по воронке, так как команда смогла лучше сконцентрироваться на конкретных задачах и стала больше помогать друг другу
Мы стали выпускать фичи сразу же после готовности и это еще больше устраивало заказчика, а нам позволяла упростить развертывание (как минимум процесс согласования) и анализировать влияние тех или иных фич независимо друг от друга.
Прошло еще около 2-3 недель, процесс стабилизировался, мы стали замечать как и где можно расширить узкие горлышки в процессе. Начали применять решения и постепенно еще больше ускорять разработку.
Например, решили централизовать сбор данных, выделить для этого отдельную группу и заготавливать некоторые типы данных на постоянной основе, чтобы всегда были свежие датасеты для переобучения старых или обучения новых моделей.
Таким образом мы пришли к идеальному формату работу для нашей команды.
Я постарался кратко изложить саму суть, без описания лишних деталей и воды, а также показать почему мы принимали те или иные решения и к чему это привело. Надеюсь, эта статья будет вам полезна и поможет в вашей практике.
P.S. очень рекомендую прочитать книгу LeanDS менеджерам или Data Science инженерам, так как это сильно прокачает как минимум какие-то аспекты ваших процессов.
Страница 2 из 2 Метод гибкого управления проектом (Agile)Для проектов, которые включают в себя значительный программный компонент, традиционный метод управления проектом может быть не столь эффективным, поскольку требования могут оказаться смутными, изменчивыми. В качестве альтернативы вы можете использовать метод гибкого управления проектом (Agile Project Management — APM), не так давно получивший популярность на рынке. Гибкие методы используются тогда, когда присутствуют следующие условия:
Рис.3 Гибкий метод разработки состоит из множества скорых итеративных циклов планирования и разработки, позволяя команде разработчиков постоянно оценивать развивающийся продукт и получать мгновенные отзывы от пользователей и участников проекта. Команда изучает и улучшает продукт, а также метод работы в каждом успешном цикле. Среда применения гибкого метода управления проектомГибкий метод разработки проводится совместно с маленькой группой, располагаемой в том же здании. Основная команда обычно состоит из двух разработчиков, которые занимаются написанием кода попарно (полноценное управление качеством) клиента/пользователя, архитектора (-ов) в области ИТ, бизнес -аналитика — и руководителя проекта. Работы выполняются на протяжении серии сессий, где команда пишет код, затем тестирует рабочие модули системы, и затем процесс повторяется. Опять-таки, это отличается от традиционного подхода, где значительное количество времени уделяется планированию и ведется обширная документация нужд и требований. Команда, применяющая гибкий метод, определяет и дает приоритеты разрабатываемым функциям на основе их ценности в бизнесе, а после того, как будут созданы критические компоненты системы, работа ведется над теми, которые имеют высший приоритет. Такой подход пригоден в случае, если предлагаемый продукт может быть доставлен клиенту пошагово. В случае, если это невозможно, функции и свойства все же могут быть разработаны и затем интегрированы в первоначальную версию системы. Компоненты гибкого методаСуществует несколько ключевых элементов, которые являются основой гибкого метода управления. Данные техники также могут быть использованы в традиционном методе для того, чтобы улучшить производительность:
Предлагаемые преимущества гибкого метода управления проектомТрадиционный подход к управлению проектом является линейным, где все делается в одном цикле. Вы детально все планируете, и как только все готово и разработано, вы сдаете проект целиком. Этот способ мышления распространился с разработки программного обеспечения также на другие проекты — и в этом различие традиционного подхода от гибкого. В случае с гибким методом управления проектом, вы планируете только столько, сколько необходимо. В то время как каждая часть системы будет разработана, команда собирает весь полученный опыт, а также отзывы клиента. Поскольку клиент видит и/или испытывает рабочий прототип, ему легче будет определить, либо переопределить требования и описать команде разработчиков то, что на самом деле нужно организации. Такой метод подразумевает изменения, которые приносят ценность и снижают затраты посредством итеративной разработки. Изменения мелкого модуля стоят дешевле, чем изменения разработанной огромной системы. Возможно ли использование метода гибкого управления проектом?По своей сути, управление проектом, будь то традиционный либо гибкий метод, имеет основной принцип в удовлетворении клиента. Суть заключается в управлении командой, в предоставлении измеримых результатов. Множество практических навыков могут быть реализованы в большинстве организационных структур командного типа. Тем не менее, некоторые профессионалы в среде управления проектами могут игнорировать данные принципы гибкого метода управления проектом в случае, если они не могут применить все навыки и компоненты — но это не будет ошибкой. К примеру, что случится, если они не смогут заставить пользователя постоянно находиться в рабочей комнате с командой при разработке? Это вовсе не означает, что они не могут использовать другие принципы гибкого метода управления — такие, как визуальный контроль и разработка на основании предоставляемых элементов. Кроме этого, даже если пользователь не может быть полностью вовлечен, многие пользователи изъявляют желание участвовать в команде, особенно во время тестирования и процесса установления приоритетов элементов. Внедрение техники гибкого метода управления в проектах предоставляет концентрацию на преимуществах каждого элемента. При традиционном подходе командам приходится завершать проект в срок и согласно бюджету, при этом теряя след того блага для организации, на которое и нацелен проект. Важно помнить о том, что стратегия заключается в улучшении проекта соответствуенно увеличению общих затрат на продукт и его дальнейшее использование, а не только затрат на выполнение проекта — в таком случае преимущества проекта будут явно выражены, независимо от того, создает команда продукт либо разрабатывает новый. Kathleen Hass
Newer news items: Older news items: |
Гибкое управление проектами — руководство для начинающих
Когда дело доходит до управления вашей работой, существуют десятки и десятков методологий управления проектами на выбор.
Но когда вы начнете исследовать, какая методология подходит именно вам, вы, вероятно, снова и снова увидите одно конкретное слово:
Agile.
Кажется, что это мерцает в вашем периферийном зрении, как какой-то мираж управления проектами. Это реально? Могут ли все общепризнанные преимущества гибкого управления проектами быть правдой? Или это просто модное словечко, которое обещает больше, чем дает?
Можно с уверенностью сказать, что вокруг преимуществ гибкого управления проектами много шума.Но что именно? И как узнать, подходит ли это для управления вашей командой?
Что такое гибкое управление проектами?
Agile-управление проектами — это итеративный подход к проектам разработки программного обеспечения, обеспечивающий возможность быстрого реагирования на обратную связь и возможность внесения соответствующих изменений на каждом этапе спринта или цикла продукта.
Это позволяет проектным группам применять гибкие методологии управления проектами для быстрой и совместной работы в рамках временных рамок и бюджета проекта.
Teamwork, которому доверяют 20 000 компаний и 6 000 агентств, позволяет легко управлять, отслеживать и настраивать несколько сложных проектов. Начните с бесплатной 30-дневной пробной версии.
Гибкое управление проектами охватывает множество различных гибких методологий управления проектами, каждая из которых основана на некоторых общих принципах и основных ценностях гибкой разработки.
Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?
Краткая история agile
Большинство современных гибких методов управления проектами берут свое начало в разработке программного обеспечения. Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.
Они обнаружили, что подводные камни этих тяжеловесных методов, такие как отсутствие гибкости, приспособляемости и даже автономии, затрудняли их реакцию на изменения или применение полученных знаний в процессе работы.Поскольку планы проекта были намечены в самом начале, не было места для неожиданностей, а отклонения могли дорого обойтись.
Но в отличие от отраслей, где процесс был фиксированным, а результат был надежным и стабильным (подумайте: производственный процесс, который создает один и тот же продукт на конвейере), изменения являются фундаментальным компонентом программных проектов.
Может быть, требования заинтересованных сторон меняются, или, может быть, тестирование показывает, что что-то работает не так, как должно, когда конечный пользователь получает это в свои руки.
Вместо того, чтобы быть в плену плана управления проектом, который они наметили в начале, гибкие методы управления проектами означали, что команды могли учитывать эти изменения для создания наилучшего продукта. Для этого им требовались более короткие циклы разработки (называемые спринтами), более итеративный процесс, а также непрерывная обратная связь и тестирование.
Затем, в 2001 году, группа разработчиков программного обеспечения собралась вместе, чтобы обсудить основные принципы Agile и по-настоящему углубиться в лежащую в его основе философию.Они придумали Манифест гибкой разработки программного обеспечения, набор ценностей и принципов, которые могли бы стать путеводной звездой для команд, задающихся вопросом, как стать гибкими.
Определение гибкого управления проектами
Если все это кажется очень ориентированным на разработку программного обеспечения, не беспокойтесь. Многие гибкие методологии управления проектами были разработаны с учетом программного обеспечения, но основные ценности и принципы гибкого управления проектами полезны для многих различных типов команд, от групп разработчиков до маркетинговых команд.
Знание истории гибкого управления проектами (или, по крайней мере, краткое изложение ее, изложенное выше) может помочь дать контекст некоторым терминам и процессам, которые до сих пор характеризуют гибкое управление проектами и которые мы вскоре рассмотрим более подробно. когда мы разберем Agile Manifesto более подробно.
Но если вы сейчас ищете просто определение гибкого управления проектами, а не предысторию того, что было раньше, вот полезное определение гибкого управления проектами.
Agile-управление проектами — это совместный итеративный подход к управлению проектами, который включает в себя непрерывное тестирование и способность реагировать на изменения.
Хорошо звучит? Давайте вернемся к Agile-манифесту, чтобы узнать больше об основных ценностях и принципах, которые вы можете использовать для руководства любым agile-проектом.
4 основных ценности Agile
Как упоминалось выше, самые ранние методы управления проектами Agile были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду.
Но не чувствуйте себя ограниченным этим.
Независимо от того, создаете ли вы программное обеспечение или что-то совершенно другое (например, маркетинговую кампанию), существует множество выводов, которые вы можете применить независимо от того, в какой отрасли вы работаете. значения:
Индивидуумы и взаимодействие над процессами и инструментами.
Работающее программное обеспечение с исчерпывающей документацией.
Сотрудничество с клиентами при заключении контракта.
Реагирование на изменение по плану.
Эти основные ценности лежат в основе всех гибких подходов к управлению проектами, на них основано все, от стандартных способов работы до 12 гибких принципов управления проектами.
Из основных ценностей становится ясно, что гибкие подходы, прежде всего, основаны на сотрудничестве и управлении людьми.
Это относится не только к рабочим процессам (прогресс достигается за счет «людей и взаимодействий» и «сотрудничества с клиентами», ставя во главу угла человеческий фактор), но и к готовой продукции.То есть цель состоит в том, чтобы создать что-то функциональное, что принесет наибольшую пользу конечному пользователю.
12 принципов гибкого управления проектами
Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:
Приоритетом номер один является удовлетворение потребностей клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения.
Приветствуйте меняющиеся разработки, даже на поздних стадиях разработки.Гибкие процессы используют изменения для конкурентного преимущества клиента.
Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
Работающее программное обеспечение является основным мерилом прогресса.
Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Когда дело доходит до дела, независимо от того, говорите ли вы о реальном программном обеспечении или используете его в качестве метафоры для всего, что вы создаете (давайте назовем это «Вещь»), гибкие методы побуждают вас создавать итерации « Вещь» быстро и часто — потому что «Вещь» лучше существовать в ущербной реальности, чем в совершенной теории.
Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.
Каковы преимущества гибкого управления проектами?
Agile-управление проектами может показаться просто модной методологией управления проектами du jour , но оказалось, что это нечто большее, чем просто вспышка.
Это потому, что результаты говорят сами за себя. Принципы Agile-управления проектами позволили командам всех типов работать более итеративно и гибко, давая им возможность адаптироваться к меняющимся требованиям проекта и быстрее выполнять поставленные задачи.
Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.
Большая адаптивность (и меньший риск)
Одним из самых больших преимуществ гибких методов является возможность управлять меняющимися приоритетами.Благодаря итеративному подходу Agile и упору на непрерывную обратную связь вы можете получать необходимые данные в процессе разработки, а не после него, что позволяет команде делать более эффективные решения на основе реальных условий, а не только прогнозируемых условий.
А благодаря назначенным коротким циклам спринтов, более четкой визуализации проекта и регулярным обновлениям отчетов команды могут повысить предсказуемость проекта и снизить риски.
Повышение удовлетворенности клиентов
Возможно, вы помните, что сотрудничество с клиентами является одной из четырех основных ценностей гибкого управления проектами.
Что ж, одно из основных преимуществ этого заключается в том, что более тесное сотрудничество с клиентами приводит к большей удовлетворенности клиентов.
Гибкие методологии управления проектами выдвигают на первый план клиента и побуждают вас тесно сотрудничать с ним, а также с другими заинтересованными сторонами, чтобы убедиться, что вы создаете что-то, что действительно решает их проблему.
А поскольку agile-проекты включают в себя регулярное тестирование и обзор при каждом спринте, вы можете получать их реальную обратную связь в режиме реального времени при каждой итерации вашего работающего продукта.
Более счастливые команды
Agile-команды более автономны. То есть им часто предоставляется свобода предлагать новые идеи, вводить новшества и решать проблемы, которых может не хватать в традиционных методологиях управления проектами.
С такой ответственностью людям доверяют выполнение работы и поощряют видеть себя неотъемлемыми членами команды, которые могут внести ощутимый вклад в конечный результат проекта.
Не только это, но и акцент на сотрудничестве и общении может способствовать созданию более прозрачных, эффективных, творческих и, да, счастливых команд.
Как стать гибким
Более качественные результаты, большее количество довольных клиентов и пользователей и повышение морального духа в команде — это может звучать слишком хорошо, чтобы быть правдой.
Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.
Чтобы гибкие методы оказали такое преобразующее воздействие, вам нужна поддержка, заинтересованность и действительно выдающиеся люди в команде.
Итак, если вам интересно, как стать гибким, вот что вам нужно иметь в виду.
Привлеките к работе нужных людей
Гибкие методологии управления проектами основаны на найме замечательных людей и предоставлении им возможности выполнять свою работу наилучшим образом. Это даже отражено в основных ценностях Agile: люди превыше процессов.
Это означает, что вам нужно сосредоточиться на подборе и найме нужных людей в первую очередь. Найдите нужных людей и высвободите их талант для решения проблем, а не бездумного выполнения приказов, и вы уже будете на полпути.
Как Teamwork использует Teamwork: набор и адаптацияИнтеграция вашей службы поддержки и приложений для управления проектами, от найма до адаптации, позволит вам создать единый рабочий процесс и поможет вам обеспечить положительный опыт кандидата от начала до конца.Вот как мы используем Teamwork внутри компании и используем интеграцию между продуктами для создания плавного и прозрачного процесса на каждом этапе процесса найма.
И привлечь к работе нужных людей
Согласно 13-му ежегодному отчету о состоянии Agile, все три главных препятствия на пути внедрения или масштабирования гибких методов управления проектами связаны с проблемами организационной культуры. К ним относятся:
Организационная культура, противоречащая ценностям Agile
Общее сопротивление организации изменениям
Неадекватная поддержка и спонсорство со стороны руководства от всех — включая руководство. Респонденты опроса высоко оценили внутренних agile-коучей, спонсорство руководителей, предоставляемые компанией программы обучения, последовательные практики и процессы в командах, а также внедрение общего инструмента в командах как 5 лучших советов, когда дело дошло до внедрения agile-методов управления проектами в компании.
Получите сертификацию
Существует распространенное заблуждение, что Agile — это всего лишь бесплатный доступ для всех, но это абсолютно не так. Agile — это не отсутствие методологии; это тип фреймворка сам по себе.
Если вы привержены гибкому управлению проектами, вы всегда можете инвестировать в получение сертификата по гибкому управлению проектами, чтобы узнать больше о гибких ценностях и принципах и понять, как они могут работать для вашей команды.
Используйте правильные инструменты управления проектами
Внедрение общего инструмента для команд не только является одним из 5 лучших способов масштабирования ваших гибких практик, но и в первую очередь важно помочь вашей команде стать гибкими.
Ищите гибкое гибкое средство управления проектами, которое поддерживает ваш стиль работы, а не диктует его. В Teamwork есть все, что вам нужно, чтобы предоставить всем в вашей команде наглядность, гибкость и возможность совместной работы, необходимые им для продвижения вперед, независимо от того, предпочитаете ли вы доски Scrum или Kanban, — и когда придет время масштабироваться, он может масштабироваться вместе с вами.
Agile и Scrum: в чем разница?
Мы уже упоминали, сколько существует типов гибкого управления проектами (ответ: столько-то ), но из множества гибких методологий есть одна, которую вам, возможно, захочется освежить в памяти.
Scrum, несомненно, является одной из самых популярных гибких методологий, используемых сегодня: целых 72% респондентов последнего отчета State of Agile заявили, что они используют «Scrum или гибрид, включающий Scrum».
Как и другие agile-методологии управления проектами, Scrum придерживается основных agile-ценностей и принципов (итераций, реакции на изменения и всего того хорошего, о чем говорилось выше).
Однако есть несколько специфичных для Scrum терминов и процессов, которые вам необходимо знать, если вы думаете о внедрении гибкого управления проектами с помощью Scrum.
Agile-управление проектами с помощью Scrum
В Scrum-команде есть три основные роли:
Владелец продукта
Лицо, ответственное за максимизацию ценности работы, выполненной Командой Разработки. Один из способов сделать это — управлять бэклогом.
Команда разработчиков
Небольшая группа людей, которые в конечном итоге работают над The Thing. Команда имеет плоскую иерархию и самоорганизуется; как только цели установлены, члены команды могут решать их по своему усмотрению.
Scrum Master
Работает, чтобы облегчить и поддержать процесс Scrum для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.
Вот примерное представление о том, как это работает:
Все, что нужно сделать команде (например, все, что необходимо для продукта), перечисляется в бэклоге и ранжируется владельцем продукта в порядке приоритета. Задача Владельца Продукта состоит в том, чтобы оптимизировать работу Команды Разработки, следя за тем, чтобы Бэклог был лучшим из возможных (т.е. понятным, доступным и организованным для достижения успеха).
Scrum использует спринты фиксированной продолжительности (обычно несколько недель, всегда меньше месяца). У каждого спринта есть предопределенная цель спринта. Элементы из Бэклога идентифицируются и обрабатываются как часть каждого Спринта.
Перед тем, как начнется спринт, вам нужно выполнить планирование спринта, чтобы выяснить, какова будет ваша цель спринта и как вы собираетесь ее достичь.
После начала Спринта Команда Разработки проводит короткую ежедневную встречу, называемую Ежедневным Скрамом, чтобы сообщить о прогрессе за предыдущий день, о том, на чем они будут сосредоточены сегодня, и обо всех выявленных рисках.
В конце каждого Спринта команда проводит Обзор Спринта (что-то вроде итогового собрания для Спринта), чтобы оценить свою работу и сообщить о следующем раунде Планирования Спринта.
Повторять, повторять, повторять.
Какая гибкая методология мне подходит?
Если вы все еще пытаетесь решить, какую методологию выбрать — Agile, Scrum, Kanban, Scrumban или какой-то другой гибрид? — помните, что вы можете начать с заимствования принципов и процессов, которые имеют смысл для вас и вашей команды.
Гибкое управление проектами. Руководство для начинающих
Когда дело доходит до управления вашей работой, существуют десятки и десятков методологий управления проектами на выбор.
Но когда вы начнете исследовать, какая методология подходит именно вам, вы, вероятно, снова и снова увидите одно конкретное слово:
Agile.
Кажется, что это мерцает в вашем периферийном зрении, как какой-то мираж управления проектами.
Это реально? Могут ли все общепризнанные преимущества гибкого управления проектами быть правдой? Или это просто модное словечко, которое обещает больше, чем дает?
Можно с уверенностью сказать, что вокруг преимуществ гибкого управления проектами много шума. Но что именно? И как узнать, подходит ли это для управления вашей командой?
Что такое гибкое управление проектами?
Agile-управление проектами — это итеративный подход к проектам разработки программного обеспечения, обеспечивающий возможность быстрого реагирования на обратную связь и возможность внесения соответствующих изменений на каждом этапе спринта или цикла продукта.
Это позволяет проектным группам применять гибкие методологии управления проектами для быстрой и совместной работы в рамках временных рамок и бюджета проекта.
Простой в использовании, мощный, когда вам это нужноTeamwork, которому доверяют 20 000 компаний и 6 000 агентств, позволяет легко управлять, отслеживать и настраивать несколько сложных проектов.
Начните с бесплатной 30-дневной пробной версии.
Гибкое управление проектами охватывает множество различных гибких методологий управления проектами, каждая из которых основана на некоторых общих принципах и основных ценностях гибкой разработки.
Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?
Краткая история agile
Большинство современных гибких методов управления проектами берут свое начало в разработке программного обеспечения.Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.
Они обнаружили, что подводные камни этих тяжеловесных методов, такие как отсутствие гибкости, приспособляемости и даже автономии, затрудняли их реакцию на изменения или применение полученных знаний в процессе работы.
Поскольку планы проекта были намечены в самом начале, не было места для неожиданностей, а отклонения могли дорого обойтись.
Но в отличие от отраслей, где процесс был фиксированным, а результат был надежным и стабильным (подумайте: производственный процесс, который создает один и тот же продукт на конвейере), изменения являются фундаментальным компонентом программных проектов.
Может быть, требования заинтересованных сторон меняются, или, может быть, тестирование показывает, что что-то работает не так, как должно, когда конечный пользователь получает это в свои руки.
Вместо того, чтобы быть в плену плана управления проектом, который они наметили в начале, гибкие методы управления проектами означали, что команды могли учитывать эти изменения для создания наилучшего продукта.Для этого им требовались более короткие циклы разработки (называемые спринтами), более итеративный процесс, а также непрерывная обратная связь и тестирование.
Затем, в 2001 году, группа разработчиков программного обеспечения собралась вместе, чтобы обсудить основные принципы Agile и по-настоящему углубиться в лежащую в его основе философию.
Они придумали Манифест гибкой разработки программного обеспечения, набор ценностей и принципов, которые могли бы стать путеводной звездой для команд, задающихся вопросом, как стать гибкими.
Определение гибкого управления проектами
Если все это кажется очень ориентированным на разработку программного обеспечения, не беспокойтесь.Многие гибкие методологии управления проектами были разработаны с учетом программного обеспечения, но основные ценности и принципы гибкого управления проектами полезны для многих различных типов команд, от групп разработчиков до маркетинговых команд.
Знание истории гибкого управления проектами (или, по крайней мере, краткое изложение ее, изложенное выше) может помочь дать контекст некоторым терминам и процессам, которые до сих пор характеризуют гибкое управление проектами и которые мы вскоре рассмотрим более подробно. когда мы разберем Agile Manifesto более подробно.
Но если вы сейчас ищете просто определение гибкого управления проектами, а не предысторию того, что было раньше, вот полезное определение гибкого управления проектами.
Agile-управление проектами — это совместный итеративный подход к управлению проектами, который включает в себя непрерывное тестирование и способность реагировать на изменения.
Хорошо звучит? Давайте вернемся к Agile-манифесту, чтобы узнать больше об основных ценностях и принципах, которые вы можете использовать для руководства любым agile-проектом.
4 основных ценности Agile
Как упоминалось выше, самые ранние методы управления проектами Agile были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду.
Но не чувствуйте себя ограниченным этим.
Создаете ли вы программное обеспечение или что-то совершенно другое (например, маркетинговую кампанию), вы можете применить множество выводов, независимо от того, в какой отрасли вы работаете.
Первоначальный манифест Agile заявляет, что Agile имеет 4 основных ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающее программное обеспечение с исчерпывающей документацией.
Сотрудничество с клиентами при заключении контракта.
Реагирование на изменение по плану.
Эти основные ценности лежат в основе всех гибких подходов к управлению проектами, на них основано все, от стандартных способов работы до 12 гибких принципов управления проектами.
Из основных ценностей становится ясно, что гибкие подходы, прежде всего, основаны на сотрудничестве и управлении людьми.
Это относится не только к рабочим процессам (прогресс достигается за счет «людей и взаимодействий» и «сотрудничества с клиентами», ставя во главу угла человеческий фактор), но и к готовой продукции. То есть цель состоит в том, чтобы создать что-то функциональное, что принесет наибольшую пользу конечному пользователю.
12 принципов гибкого управления проектами
Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами.
По словам самого манифеста, это:
Приоритетом номер один является удовлетворение потребностей клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения.
Приветствуйте меняющиеся разработки, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Создавайте проекты вокруг мотивированных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
Работающее программное обеспечение является основным мерилом прогресса.
Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Когда дело доходит до дела, независимо от того, говорите ли вы о реальном программном обеспечении или используете его в качестве метафоры для всего, что вы создаете (давайте назовем это «Вещь»), гибкие методы побуждают вас создавать итерации « Вещь» быстро и часто — потому что «Вещь» лучше существовать в ущербной реальности, чем в совершенной теории.
Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.
Каковы преимущества гибкого управления проектами?
Agile-управление проектами может показаться просто модной методологией управления проектами du jour , но оказалось, что это нечто большее, чем просто вспышка.
Это потому, что результаты говорят сами за себя. Принципы Agile-управления проектами позволили командам всех типов работать более итеративно и гибко, давая им возможность адаптироваться к меняющимся требованиям проекта и быстрее выполнять поставленные задачи.
Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.
Большая адаптивность (и меньший риск)
Одним из самых больших преимуществ гибких методов является возможность управлять меняющимися приоритетами.Благодаря итеративному подходу Agile и упору на непрерывную обратную связь вы можете получать необходимые данные в процессе разработки, а не после него, что позволяет команде делать более эффективные решения на основе реальных условий, а не только прогнозируемых условий.
А благодаря назначенным коротким циклам спринтов, более четкой визуализации проекта и регулярным обновлениям отчетов команды могут повысить предсказуемость проекта и снизить риски.
Повышение удовлетворенности клиентов
Возможно, вы помните, что сотрудничество с клиентами является одной из четырех основных ценностей гибкого управления проектами.
Что ж, одно из основных преимуществ этого заключается в том, что более тесное сотрудничество с клиентами приводит к большей удовлетворенности клиентов.
Гибкие методологии управления проектами выдвигают на первый план клиента и побуждают вас тесно сотрудничать с ним, а также с другими заинтересованными сторонами, чтобы убедиться, что вы создаете что-то, что действительно решает их проблему.
А поскольку agile-проекты включают в себя регулярное тестирование и обзор при каждом спринте, вы можете получать их реальную обратную связь в режиме реального времени при каждой итерации вашего работающего продукта.
Более счастливые команды
Agile-команды более автономны. То есть им часто предоставляется свобода предлагать новые идеи, вводить новшества и решать проблемы, которых может не хватать в традиционных методологиях управления проектами.
С такой ответственностью людям доверяют выполнение работы и поощряют видеть себя неотъемлемыми членами команды, которые могут внести ощутимый вклад в конечный результат проекта.
Не только это, но и акцент на сотрудничестве и общении может способствовать созданию более прозрачных, эффективных, творческих и, да, счастливых команд.
Как стать гибким
Более качественные результаты, большее количество довольных клиентов и пользователей и повышение морального духа в команде — это может звучать слишком хорошо, чтобы быть правдой.
Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.
Чтобы гибкие методы оказали такое преобразующее воздействие, вам нужна поддержка, заинтересованность и действительно выдающиеся люди в команде.
Итак, если вам интересно, как стать гибким, вот что вам нужно иметь в виду.
Привлеките к работе нужных людей
Гибкие методологии управления проектами основаны на найме замечательных людей и предоставлении им возможности выполнять свою работу наилучшим образом. Это даже отражено в основных ценностях Agile: люди превыше процессов.
Это означает, что вам нужно сосредоточиться на подборе и найме нужных людей в первую очередь. Найдите нужных людей и высвободите их талант для решения проблем, а не бездумного выполнения приказов, и вы уже будете на полпути.
Как Teamwork использует Teamwork: набор и адаптацияИнтеграция вашей службы поддержки и приложений для управления проектами, от найма до адаптации, позволит вам создать единый рабочий процесс и поможет вам обеспечить положительный опыт кандидата от начала до конца.
Вот как мы используем Teamwork внутри компании и используем интеграцию между продуктами для создания плавного и прозрачного процесса на каждом этапе процесса найма.
И привлечь к работе нужных людей
Согласно 13-му ежегодному отчету о состоянии Agile, все три главных препятствия на пути внедрения или масштабирования гибких методов управления проектами связаны с проблемами организационной культуры.К ним относятся:
Организационная культура, противоречащая ценностям Agile
Общее сопротивление организации изменениям
Неадекватная поддержка и спонсорство со стороны руководства от всех — включая руководство. Респонденты опроса высоко оценили внутренних agile-коучей, спонсорство руководителей, предоставляемые компанией программы обучения, последовательные практики и процессы в командах, а также внедрение общего инструмента в командах как 5 лучших советов, когда дело дошло до внедрения agile-методов управления проектами в компании.
Получите сертификацию
Существует распространенное заблуждение, что Agile — это всего лишь бесплатный доступ для всех, но это абсолютно не так. Agile — это не отсутствие методологии; это тип фреймворка сам по себе.
Если вы привержены гибкому управлению проектами, вы всегда можете инвестировать в получение сертификата по гибкому управлению проектами, чтобы узнать больше о гибких ценностях и принципах и понять, как они могут работать для вашей команды.
Используйте правильные инструменты управления проектами
Внедрение общего инструмента для команд не только является одним из 5 лучших способов масштабирования ваших гибких практик, но и в первую очередь важно помочь вашей команде стать гибкими.
Ищите гибкое гибкое средство управления проектами, которое поддерживает ваш стиль работы, а не диктует его. В Teamwork есть все, что вам нужно, чтобы предоставить всем в вашей команде наглядность, гибкость и возможность совместной работы, необходимые им для продвижения вперед, независимо от того, предпочитаете ли вы доски Scrum или Kanban, — и когда придет время масштабироваться, он может масштабироваться вместе с вами.
Agile и Scrum: в чем разница?
Мы уже упоминали, сколько существует типов гибкого управления проектами (ответ: столько-то ), но из множества гибких методологий есть одна, которую вам, возможно, захочется освежить в памяти.
Scrum, несомненно, является одной из самых популярных гибких методологий, используемых сегодня: целых 72% респондентов последнего отчета State of Agile заявили, что они используют «Scrum или гибрид, включающий Scrum».
Как и другие agile-методологии управления проектами, Scrum придерживается основных agile-ценностей и принципов (итераций, реакции на изменения и всего того хорошего, о чем говорилось выше).
Однако есть несколько специфичных для Scrum терминов и процессов, которые вам необходимо знать, если вы думаете о внедрении гибкого управления проектами с помощью Scrum.
Agile-управление проектами с помощью Scrum
В Scrum-команде есть три основные роли:
Владелец продукта
Лицо, ответственное за максимизацию ценности работы, выполненной Командой Разработки.
Один из способов сделать это — управлять бэклогом.
Команда разработчиков
Небольшая группа людей, которые в конечном итоге работают над The Thing. Команда имеет плоскую иерархию и самоорганизуется; как только цели установлены, члены команды могут решать их по своему усмотрению.
Scrum Master
Работает, чтобы облегчить и поддержать процесс Scrum для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.
Вот примерное представление о том, как это работает:
Все, что нужно сделать команде (например, все, что необходимо для продукта), перечисляется в бэклоге и ранжируется владельцем продукта в порядке приоритета. Задача Владельца Продукта состоит в том, чтобы оптимизировать работу Команды Разработки, следя за тем, чтобы Бэклог был лучшим из возможных (т.е. понятным, доступным и организованным для достижения успеха).
Scrum использует спринты фиксированной продолжительности (обычно несколько недель, всегда меньше месяца).
У каждого спринта есть предопределенная цель спринта. Элементы из Бэклога идентифицируются и обрабатываются как часть каждого Спринта.
Перед тем, как начнется спринт, вам нужно выполнить планирование спринта, чтобы выяснить, какова будет ваша цель спринта и как вы собираетесь ее достичь.
После начала Спринта Команда Разработки проводит короткую ежедневную встречу, называемую Ежедневным Скрамом, чтобы сообщить о прогрессе за предыдущий день, о том, на чем они будут сосредоточены сегодня, и обо всех выявленных рисках.
В конце каждого Спринта команда проводит Обзор Спринта (что-то вроде итогового собрания для Спринта), чтобы оценить свою работу и сообщить о следующем раунде Планирования Спринта.
Повторять, повторять, повторять.
Какая гибкая методология мне подходит?
Если вы все еще пытаетесь решить, какую методологию выбрать — Agile, Scrum, Kanban, Scrumban или какой-то другой гибрид? — помните, что вы можете начать с заимствования принципов и процессов, которые имеют смысл для вас и вашей команды.
Что такое гибкое управление проектами? Полное руководство
Agile-управление проектами — это итеративный подход, направленный на частое предоставление ценности и быструю обратную связь с рынком для быстрой адаптации к возникающим изменениям. Он фокусируется на:
- работа с небольшими партиями;
- визуализация процессов для создания прозрачности;
- совместная работа с заказчиком и
- получить обратную связь как можно быстрее.
Это позволяет вам быстро адаптироваться к изменяющимся требованиям и производить более качественные продукты или услуги, чтобы лучше удовлетворять потребности ваших клиентов.
Здесь мы также должны упомянуть, что распространенное заблуждение об Agile заключается в том, что это методология. Вместо этого Agile — это образ мышления для совместного решения проблем и подход, который люди применяют к современному управлению проектами.
Содержание
Краткая история Agile
Первоначально укоренившись в индустрии разработки программного обеспечения, давайте быстро рассмотрим , как возникла идея Agile-управления проектами .
Все началось с так называемого «кризиса разработки приложений» в начале 1990-х годов. В то время между потребностью бизнеса в приложении и фактической поставкой программного обеспечения существовала задержка около трех лет. Часто к моменту выпуска конечного продукта технология уже была другой, или требования заказчика кардинально изменились. Это привело ко многим неудачным проектам и невозвратным затратам.
Чрезвычайно долгие сроки выполнения проекта привели к разочарованию лидеров мнений в индустрии разработки программного обеспечения.Они начали организовывать между собой неформальные встречи, полные решимости найти способ более простой и эффективной разработки программных решений.
Так появилась знаменитая встреча 17 лидеров по разработке программного обеспечения на горнолыжном курорте Сноуберд в горах Уосатч в штате Юта в период с 11 по 13 февраля 2001 года. Группа встретилась, чтобы поговорить о лыжах, выпить, поесть и расслабиться. . Однако в конечном итоге появился «Манифест Agile», изменивший то, как мы сегодня управляем проектами.
Что такое Agile-управление проектами?
В основе Agile-управления проектами лежит слово «agility», что означает «мобильность, ловкость», а также от латинского «agere»: «делать, действовать». Это означает способность быстро продвигать что-то вперед, что позволяет легко менять направление.
Итак, с точки зрения управления проектами, «гибкость» имеет пять основных атрибутов, которые образуют строительные блоки Agile-процесса :
- Прозрачность
- Ориентация на клиента
- Адаптивность
- Чувство собственности (эффективное лидерство)
- Постоянное совершенствование
В совокупности они делают проект Agile.Чтобы обсудить их более подробно, давайте разберем каждый из них ниже:
Прозрачность
Одной из центральных тем Agile-управления проектами является общее понимание процесса (включая определение готовности) всеми заинтересованными сторонами. Это требует большей прозрачности в том, как команды работают и общаются.
В Agile-среде люди открыто делятся своим прогрессом в работе , интегрируя информационные излучатели, такие как доски Канбан. Это позволяет всем понять, что делают их коллеги и как они это делают, что, в свою очередь, позволяет обсуждать, как сделать это лучше.
Кроме того, членам команды предлагается свободно делиться своими идеями и вызовами , не опасаясь, что это может поставить под угрозу их статус в проекте. В результате подход Agile к управлению проектами направлен на создание среды единства, в которой команды признают свои ошибки и коллективно работают над их устранением.
10-летний опыт Канбана в 1 бесплатной книге:
Руководство руководителя проекта по Канбану
Ориентация на клиента
Известная цитата серийного предпринимателя Дейва Макклюра гласит: «Клиентов не волнует ваше решение.
Они заботятся о своих проблемах». Другими словами, даже если у вас есть лучшее решение в мире, если ваши клиенты не увидят, как на самом деле оно поможет им решить их проблему, они не захотят его использовать.
Вот почему Agile-подход к управлению проектами уделяет большое внимание обеспечению четкого понимания требований клиентов посредством постоянного сотрудничества. Цель состоит в том, чтобы предоставить клиентам не только то, что они просили, но и то, что им нужно. Это обычная проблема в среде умственного труда, когда работа практически невидима; его характеристики могут быть легко неправильно поняты.
Таким образом, частые циклы обратной связи в жизненном цикле реализации Agile-проекта служат контрольными точками , где клиенты могут увидеть, как «то, что, по их мнению, они хотели», на самом деле выглядит на практике. Это способствует развитию новых знаний и поиску возможных инновационных решений.
Кроме того, благодаря частому сотрудничеству с клиентами Agile стремится повысить эффективность проектов.
Один из способов добиться этого — сократить обширную переработку проекта, которая приводит к массовым потерям времени и ресурсов.В результате Agile-проекты обеспечивают более низкие уровни производства и задержки, что делает конечный продукт или услугу дешевле для конечного потребителя.
Адаптивность
Другая основная идея Agile-управления проектами состоит в том, чтобы позволить командам лучше реагировать на изменения благодаря контрольным точкам, упомянутым выше. Это также требует более частого предоставления ценности конечному потребителю, чтобы команды могли быстро получать отзывы непосредственно с рынка .
Вот почему вместо того, чтобы выполнять одну большую партию работы, Agile фокусируется на итеративном подходе, когда команды разбивают свои проекты и непрерывно выполняют их небольшими частями, сохраняя при этом гибкость для оставшейся работы.
Цель состоит в том, чтобы гарантировать, что то, над чем ведется работа, синхронизировано с конечным пользователем вместе с жизненным циклом Agile-проекта.
В результате вы будете учитывать любые изменяющиеся требования клиентов на ранней стадии процесса, быстро адаптируетесь к новой ситуации и избежите значительных задержек в окончательной реализации проекта.
Чтобы лучше проиллюстрировать этот цикл непрерывной адаптации, давайте кратко рассмотрим этапы Agile.
Каковы этапы гибкого управления проектами?
В целом процесс реализации Agile-проекта можно разделить на следующие этапы:
- Envision – создать высокоуровневое видение продукта/услуги для клиентов, а также определить, кто будет вовлечен в проект
- Спекуляция — это продолжение этапа «Представление», когда команды собирают исходные общие требования к продукту/услуге и разрабатывают план итерации на основе видения.
- Исследуйте — работайте над результатами проекта, уделяя особое внимание потоку, стремясь как можно быстрее получить обратную связь от клиента
- Адаптировать – просмотреть полученные результаты и при необходимости адаптировать к текущим условиям
- Закрыть – завершить проект, передать основные выводы
Традиционное и гибкое управление проектами
В Agile-менеджменте, в отличие от традиционных этапов управления проектами, есть одно ключевое отличие на этапе «Адаптация», которое определяет итеративный характер Agile-управления проектами.
После того, как вы создали концепцию продукта и подготовили план итерации, вы переходите к этапу «Изучение». Там цель состоит в том, чтобы постоянно выпускать на рынок небольшие результаты, а не ждать, пока все они будут завершены.
Затем, на этапе «Адаптация», команды проводят краткие обзоры проекта с клиентами, которые оставляют свои отзывы. Идея состоит в том, чтобы адаптировать ваши будущие действия на основе этой обратной связи и, при необходимости, внести небольшие изменения в то, что было доставлено, вместо того, чтобы делать обширную переработку.
Чувство собственности
Другим атрибутом, который «гибкость» привносит в управление проектами, является привитие чувства сопричастности в командах, что способствует более эффективному лидерству.
Например, в традиционном управлении проектами вся информация проходит через специального менеджера проекта, который распределяет задачи между разными членами команды. Это может быть неэффективно из-за повышенной вероятности потери части информации.
Напротив, проекты Agile отдают большой фрагмент процесса принятия решений членам команды .
На самом деле, именно они наиболее близки к техническим деталям работы, поэтому имеет смысл активно включать их в процессы планирования и решать, как лучше всего выполнять свои задачи. В конце концов, членам команды предлагается сотрудничать и находить решения проблем на основе их понимания, а не ждать, пока «босс» скажет, что нужно сделать.
Это создает среду совместного владения, которая мотивирует и дает возможность командам работать более эффективно .В результате они будут вносить наилучший вклад в завершение проекта.
В свою очередь, руководство становится более эффективным, поскольку его внимание переключается на управление работой (а не рабочими), которая приносит прибыль бизнесу. Поэтому успешные Agile-лидеры ставят перед членами своей команды общие цели, помогают устранять препятствия, оптимизируя рабочий процесс, предоставляют необходимые ресурсы и поощряют совместное обучение.
Постоянное совершенствование
Одним из наиболее важных свойств Agile-управления проектами является то, что оно создает среду для постоянного совершенствования.Команды регулярно участвуют в частых циклах обучения одновременно с разработкой проекта вместо одной большой сессии «извлеченных уроков» в конце.
Это гарантирует, что существенные улучшения процессов будут происходить, пока Agile-проект все еще находится в движении, что может положительно повлиять на успешную доставку окончательного решения конечным клиентам. Конечно, нет ничего плохого в другом подходе, который до сих пор присутствует в Agile-процессе управления проектами.Однако в среде, где работа невидима и часто происходят изменения, полагаться только на это оказывается неэффективным для успешной реализации Agile-проекта.
Кроме того, работа разбивается на небольшие результаты и непрерывно передается клиентам для изучения и обратной связи .
Это также способствует постоянному совершенствованию продукта или услуги с целью сделать их идеально подходящими для целевого клиента.
Agile-ценности и принципы
Чтобы стать гибким, нужно изменить свое мышление и следовать определенным ценностям и принципам в своей работе.
Каковы
четыре ключевых ценности Agile ?- Индивидуумы и взаимодействия важнее процессов и инструментов.
- Рабочее программное обеспечение по исчерпывающей документации.
- Сотрудничество с клиентами в ходе переговоров по контракту.
- Реакция на переход по плану.
Важно отметить, что эти значения были определены в следующем формате: «Хотя мы ценим то, что справа, мы больше ценим то, что слева».Это означает, что процессы и инструменты, документация, контракты и планирование по-прежнему имеют основополагающее значение. Мы просто должны использовать их с умом.
Каковы 12 принципов Agile?
- Наивысшим приоритетом является удовлетворение клиента путем ранней и непрерывной поставки ценного программного обеспечения.
- Изменения требований следует приветствовать даже на поздних этапах разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
- Работающее программное обеспечение должно поставляться часто , от пары недель до пары месяцев, предпочтительно в более короткие сроки.
- Деловые люди и разработчики программного обеспечения должны работать вместе ежедневно на протяжении всего проекта.
- Создание проектов вокруг мотивированных людей . Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
- Наиболее эффективным и действенным методом передачи информации команде разработчиков и внутри нее является беседа лицом к лицу .
- Работающее программное обеспечение является основным показателем прогресса.
- Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок .
- Постоянное внимание к техническому совершенству и хороший дизайн повышают маневренность.
- Простота – искусство максимизировать объем незавершенной работы – очень важно.
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами .
- Через равные промежутки времени команда размышляет о том, как стать более эффективной , а затем соответствующим образом настраивает и корректирует свое поведение.
Узнайте больше о 12 принципах гибкого управления проектами.
Несмотря на то, что управление проектами Agile происходит из индустрии разработки программного обеспечения, оно успешно применяется во многих других областях, таких как разработка продуктов, архитектура, маркетинг, финансовые услуги и т. д.
Гибкие методы управления проектами
До сих пор мы в основном изучали, что такое Agile-управление проектами, включая его основные характеристики.
Теперь давайте рассмотрим процесс более подробно и коснемся некоторых наиболее популярных стилей и методов управления Agile.
Поскольку Agile стал горячей темой в начале 21-го века, многие фреймворки воспользовались растущим ажиотажем и быстро прославились (Scrum, SAFe и т. д.). Однако многие компании, стремящиеся к реальной бизнес-гибкости, осознали, что строго предписывающие рамки и гибкость — это полная противоположность. Вот почему сегодня многие организации обращаются к методологиям Agile, которые создают и поддерживают стабильный рабочий процесс и адаптируют процессы к их собственным потребностям, вместо того, чтобы внедрять строго предписывающие рамки.
На сегодняшний день самыми популярными фреймворками или методами управления проектами Agile являются Kanban, Scrum и Scrumban.
Итак, начнем с Канбана.
Канбан
Канбан — это метод, сформулированный десять лет назад. Он фокусируется на эволюционных изменениях и постоянном совершенствовании процессов .
Метод состоит из шести основных практик:
- визуализировать работу
- ограничение незавершенного производства
- управлять потоком
- сделать политики процессов явными
- внедрить петли обратной связи
- улучшить совместно
Команды визуализируют свою работу на канбан-доске, которая служит центральным информационным центром, где должны размещаться все задачи.Это позволит людям намного быстрее обмениваться информацией и более эффективно сотрудничать при работе над разными проектами.Канбан-доска разделена на столбцы, представляющие различные этапы рабочего процесса. Это помогает менеджерам проектов и командам намного лучше организовывать работу и управлять ею, отслеживать различные проекты и получать более полное представление о процессе.
Одной из наиболее важных практик Канбана является ограничение незавершенного производства. Ограничение WIP — это объем работы, разрешенный для каждой из колонок доски.
Это один из самых эффективных инструментов, который вы можете использовать, чтобы повысить концентрацию вашей команды и расставить приоритеты в отделочных работах для повышения общей эффективности.
С другой стороны, все мы знаем, что проекты, команды и отдельные люди уникальны. Разные команды обладают разным набором навыков, уровнем опыта, экспертизы. Различные проекты могут иметь разные масштабы, бюджеты и так далее.
Вот почему Канбан предлагает вам начать с того, что вы делаете сейчас, и постепенно развиваться . Никаких радикальных изменений, никаких революций, что делает Канбан одним из самых адаптивных методов управления проектами Agile.
Канбан может применяться любой командой в вашей организации, от ИТ до маркетинга. Основная причина в том, что Канбан:
- уважает текущие процессы и роли;
- требует не революционных, а эволюционных изменений;
- предполагает, что вы должны стремиться к постепенным, эволюционным изменениям и пытаться постоянно совершенствоваться;
- призывает управлять работой и позволять людям самоорганизовываться вокруг нее.
Если вы хотите использовать Канбан, просто добавьте его к своим текущим процессам и начните улучшать их шаг за шагом.
Узнайте больше о Канбане.
Скрам
Многие считают, что Scrum — это метод Agile, но на самом деле это предписывающая структура. По своей сути это итеративный подход, который использует ограниченные по времени интервалы и разбивает проекты на фиксированные периоды, называемые спринтами. Основная цель — помочь командам продуктивно и творчески создавать продукты максимально возможной ценности .
Есть три неизменяемые роли:
- Владелец продукта
- Скрам-мастер
- Команда
Владелец продукта представляет клиентов и другие заинтересованные стороны.Он/она организует и управляет бэклогом продукта, списком приоритетных задач всех рабочих элементов, необходимых для продукта. С другой стороны, Скрам-мастер — это лидер-слуга команды с упором на лидерство и помогает всем понять и правильно применять правила.
Из невыполненной работы продукта рабочие элементы выбираются и перемещаются в невыполненную работу спринта до тех пор, пока не будет достигнута емкость для спринта. Самоорганизованная или самоуправляемая команда сама выполняет работу во время Спринта, который можно рассматривать как проекты с фиксированной продолжительностью не более одного месяца.
Есть четыре основных события Scrum:
- Планирование спринта
- Ежедневная схватка
- Обзор спринта
- Ретроспектива спринта
Интересно, что в оригинальной статье, в которой формулируется структура, а затем и в руководстве по Scrum, авторы никогда не упоминают об использовании доски задач.
Однако в настоящее время вы можете заметить, что все команды или организации используют доску задач, практикуя Agile-управление проектами с помощью Scrum, практики, заимствованной из Kanban.
В конце концов, доска повышает прозрачность и поддерживает ценности Agile-управления проектами.
Скрамбан
По мере того, как канбан становился все более и более популярным, некоторые представители Agile-сообщества увидели возможность разработать метод, облегчающий скрам-командам движение вперед и сосредоточение на постоянном совершенствовании и эволюционных изменениях. Так родился Scrumban.
Интересен тот факт, что 81% Скрам-мастеров используют Канбан вместе со Скрамом.
Scrumban берет философию и практику Канбана, кладет их поверх Scrum и устраняет некоторые правила.
Посмотрим, что Скрамбан возьмет из Канбана.
Визуализация работы . Это первое, что Scrumban прописывает как обязательное. Это важно, потому что Scrum не требует наличия совета, в то время как в Kanban совет необходим.
Ограничение незавершенного производства (WIP) . Если вы что-нибудь знаете о Канбане, то понимаете, что ограничение незавершенного производства меняет правила игры.Scrumban использует эту практику и успешно применяет ее, поскольку это позволяет командам сосредоточиться на завершении работы.
Ограничение незавершенного производства является хорошей предпосылкой для создания вытягивающей системы, в которой задачи естественным образом включаются в рабочий процесс, а не проталкиваются.
Удлинить плату . Другими словами, добавьте больше столбцов на доску. Это типично для Канбана, и это отличный способ визуализировать различные этапы рабочего процесса на доске. Таким образом, ваша команда сможет получить более полное представление о процессе, и это поможет вам обнаружить, где именно в процессе возникают узкие места.
Расстановка приоритетов . Scrumban применяет еще одну технику Канбана — расстановку приоритетов. Это довольно просто. Вы упорядочиваете карточки в колонке «Запрошено (сделать)», и существует простое правило: верхняя — самая важная. Помня об этом правиле, команда начинает вытягивать карты одну за другой.
(Стоп) Оценка . Вероятно, именно здесь Scrumban обманывает Scrum. Это почему? Scrumban утверждает, что вам не нужно оценивать работу.
Вот в чем дело.Согласно бережливому производству, любое действие, не добавляющее ценности результату, считается отходами. В этом смысле оценка является расточительной деятельностью. Вот почему в Scrumban сессии планирования относительно короткие и сосредоточены на расстановке приоритетов, а не на оценке.
Планирование по требованию . Это одно из основных отличий Scrum от Scrumban. Scrumban устраняет планирование спринта в его первоначальной форме. Вместо этого команда планирует, есть ли в этом потребность. Другими словами, команда извлекает рабочие элементы из невыполненной работы до тех пор, пока она не опустеет, что является триггером для планирования дополнительных задач.Как видите, Scrumban выводит Scrum на новый уровень, применяя принципы и практики Канбан. Это позволяет командам увеличить производительность и сократить количество отходов, обеспечивая при этом прозрачность и более высокую производительность. Это также позволяет командам использовать Agile-планирование в полной мере.
Другие почетные упоминания
Существуют и другие методы управления Agile-проектами, которые оказали положительное влияние на развитие Agile-сообщества, но с течением времени они постепенно отодвигались в сторону. Поэтому мы не будем посвящать им отдельные абзацы.Однако мы должны упомянуть, что некоторые из них:
- XP (экстремальное программирование)
- Кристаллические методы
- FDD (Функция разработки)
- DAD (дисциплинированная гибкая поставка)
В начале Scrum был принят довольно хорошо (и до сих пор остается), и он стал основным в индустрии разработки программного обеспечения. Однако с течением времени использование Канбан, Скрамбан и гибридных моделей становилось все более популярным и способствовало распространению Agile в различных отраслях.В конце концов, Kanban, Scrum и Scrumban входят в тройку лидеров, которые успешно преодолели пропасть и распространились на другие сектора, такие как разработка продуктов, архитектура, маркетинг, финансовые услуги, здравоохранение, страхование, образование и другие.
Попробуйте Kanbanize бесплатно
ВкратцеПодход Agile к управлению проектами позволяет вашей организации быть более гибкой и находить способ реагировать на возникающие изменения. Проект считается гибким, если присутствуют следующие атрибуты:
.- Прозрачность
- Ориентация на клиента
- Адаптивность
- Чувство собственности (совместное лидерство)
- Постоянное совершенствование
Что такое гибкая методология управления проектами?
Каждая технологическая компания понимает, что искусство разработки программного обеспечения уникально — оно требует заботы и внимания адаптируемой команды, которая готова быстро реагировать на изменения.Вот тут-то и появляется Agile-управление проектами.
Чем Agile отличается от других методологий управления проектами? В этом подробном руководстве мы расскажем вам все, что вам нужно знать об Agile. Мы разберем историю Agile, 4 ключевых столпа Agile и 12 принципов Agile.
Что такое гибкая методология?Кроме того, мы расскажем, как компании могут использовать Agile, а также инструменты, которые они могут использовать для реализации Agile-управления проектами.
Agile-методология управления проектами относится к способности создавать изменения и действовать в соответствии с ними.Это способ справиться и в конечном итоге добиться успеха в непредсказуемой среде. По словам создателей манифеста Agile, Agile представляет собой адаптивность и отзывчивость к изменениям.
Речь идет о командах, понимающих, что происходит в окружающей среде, определяющих, с какой неопределенностью они сталкиваются, и выясняющих, как они могут адаптироваться по мере продвижения вперед.
Проще говоря, Agile — это итеративный подход как к разработке программного обеспечения, так и к управлению проектами, основанный на постоянном планировании, обучении, развитии, командной работе, эволюционном улучшении и скорейшей реализации.Его конечная цель — вдохновить на гибкую реакцию на изменения.
С помощью Agile команды могут управлять несколькими проектами, разбивая их на разные этапы и постоянно привлекая к сотрудничеству заинтересованных лиц. На каждом этапе происходит непрерывное развитие и итерация.
Agile помогает команде быстро и легко создавать ценность для своих клиентов. Вместо того, чтобы зависеть от запуска большого взрыва, команда представляет работу небольшими, но расходными частями. Agile-команды постоянно оценивают требования, планы и результаты, а это означает, что у них есть регулярная процедура быстрого реагирования на изменения.
Итак, в чем основные различия между Agile и Waterfall? В то время как традиционный подход Waterfall требовал, чтобы один человек внес свой вклад в целое, прежде чем передать его следующему органу или участнику, Agile требует сотрудничества межфункциональных команд. Адаптация, сотрудничество, доверие и открытое общение между участниками команды — сердце Agile.
Несмотря на то, что владельцы продукта или руководители проектов диктуют, как должна выполняться работа, команды самоорганизуются вокруг второстепенных задач и назначений, чтобы определить, как они будут выполнять работу.
История метода AgileИстория Agile началась не с Манифеста Agile. Его корни уходят в 1950-е и 1960-е годы, но настоящий взлет он получил в 1990-х, когда появилось много подходов Agile к разработке программного обеспечения. Именно тогда Agile-методология начала приобретать огромное количество поклонников.
В 2001 году группа из 17 дальновидных разработчиков программного обеспечения провела встречу в Юте, чтобы обсудить отраслевые проблемы и возможные решения. Позже они создали то, что известно в отрасли как Agile Manifesto .Манифест Agile включает в себя некоторые принципы и ценности, которым необходимо следовать, чтобы обеспечить окончательный успех продукта.
Эта группа ведущих разработчиков понимала, что индустрия программного обеспечения нуждается в лучшем способе управления проектами и доставки продуктов на рынок. Их основной целью было создание альтернативных методов управления проектами и разработки продуктов без существенного влияния на стоимость проекта или график выпуска продукта.
Они согласились, что разделение проекта на несколько более мелких спринтов позволит ускорить разработку и тестирование.Клиенты могли просматривать продукт, а команда могла вносить изменения, не дожидаясь финального продукта. Отсюда и возник термин Agile-методология разработки программного обеспечения.
Сегодня у Agile есть обширное сообщество, состоящее из людей, занимающихся Agile-разработкой программного обеспечения, и организаций, которые помогают им посредством обучения, инструментов, фреймворков и консультаций. Agile Product Development Methodology теперь используется для запуска проектов в компаниях любого размера, от небольших стартапов до крупных предприятий, и охватывает многие отрасли по всему миру.
Четыре столпа Agile 1. Индивиды и взаимодействие в процессах и инструментахИменно люди реагируют на потребности бизнеса и управляют процессом разработки, поэтому имеет смысл рассматривать их в первую очередь и ценить выше, чем процессы и инструменты.
2.Рабочее программное обеспечение по исчерпывающей документацииКогда процессы и инструменты стимулируют развитие, команда становится менее отзывчивой и с меньшей вероятностью удовлетворяет потребности клиентов.
До применения методологии Agile компании тратили много времени на подготовку документации по продукту, что приводило к длительным задержкам в развертывании продуктов.
Agile не избавляется от обширной документации; скорее, он упрощает его таким образом, что разработчик программного обеспечения точно знает, над чем ему или ей нужно работать. Их не связывают сложности или слишком много деталей.
Agile-документы, такие как пользовательские истории, могут дать разработчику достаточно информации для создания нового функционального продукта.Хотя Agile ценит исчерпывающую документацию, он больше ценит работающее программное обеспечение.
3. Сотрудничество с заказчиком при заключении контрактаВ ходе переговоров по контракту заказчик подробно обсуждает требования к продукту с организацией, прежде чем можно будет начать какую-либо работу.
Это означает, что клиент является лишь частью разработки продукта до начала процесса и после его завершения.
Однако Agile использует другой подход и включает сотрудничество с клиентами.Он вовлекает клиента на каждом этапе разработки продукта от начала до конца. Это облегчает разработчикам работу с любыми изменениями, которые могут возникнуть для удовлетворения потребностей клиентов.
4. Реагирование на переход по плануИзменения неизбежны. Однако традиционные подходы к разработке программного обеспечения рассматривают изменения как расходы, которых необходимо избегать любой ценой. Разработчики программного обеспечения в то время разрабатывали подробные и четкие планы с определенным набором функций для разработки продукта, но они обычно не учитывали изменения, которые сильно сказываются на потребностях клиента.С помощью измененного программного обеспечения разработчики могут изменять определенные функции продукта в соответствии с потребностями клиента.
12 принципов Agile- Удовлетворение потребностей клиентов за счет ранней и непрерывной разработки программного обеспечения.
- Примите меняющиеся требования в процессе разработки программного обеспечения.
- Концентрация на частой поставке рабочего программного обеспечения.
- Заинтересованные стороны бизнеса и разработчики программного обеспечения сотрудничают на протяжении всего процесса разработки.
- Обеспечьте надлежащую среду и поддержку команде разработчиков, чтобы они могли чувствовать себя мотивированными. Доверие также необходимо.
- Общение лицом к лицу упрощает обмен информацией между владельцами проекта и командами.
- Функциональное программное обеспечение является истинным мерилом прогресса.
- Процесс разработки Agile поддерживает устойчивое развитие. Заинтересованные стороны бизнеса, разработчики и клиенты должны иметь возможность поддерживать постоянный и неопределенный темп.
- Постоянное внимание к хорошему дизайну и техническому совершенству повышает маневренность.
- Простота необходима, поскольку она предполагает максимальное увеличение незавершенной работы.
- Самоорганизованные команды часто создают лучшие решения.
- Часто команда размышляет о том, как стать более эффективной, и соответствующим образом корректирует свое поведение.
Гибкое управление проектами: Гибкое управление проектами относится к методу разработки небольших частей программного обеспечения в частом цикле итераций на основе меняющейся среды.
Критерии приемлемости: Эта фраза определяет набор требований, которым должно соответствовать программное обеспечение, чтобы оно могло удовлетворить потребности клиента. Владельцы продукта обычно пишут заявление с точки зрения клиента, объясняющее, как должна работать пользовательская история. Чтобы история была принята, она должна соответствовать критериям приемлемости.
Приемочное испытание : Приемочное испытание подтверждает, работает ли функция. Результат теста — зачет или провал.Чаще всего приемочные испытания автоматизированы, то есть команды могут выполнять их на всех версиях программного обеспечения. Критерии приемки обычно содержат один или несколько приемочных тестов.
Управление жизненным циклом приложений (ALM): Это относится к непрерывному процессу управления разработкой программного приложения от начальной стадии планирования до стадии вывода из эксплуатации. Он используется на протяжении всего проекта и использует инструменты, помогающие в управлении требованиями, проектировании, кодировании, тестировании, отслеживании и выпуске.
Незавершенная работа: Незавершенная работа — это список требований к продукту, которые постоянно меняются в зависимости от потребностей клиента. Это полный список всех необходимых функций продукта. Agile-команды используют бэклог, чтобы отдать приоритет определенным функциям и понять, какие функции требуют реализации.
Уход за невыполненной работой: Уход за невыполненной работой — это когда остальная часть команды или владелец продукта ежедневно уточняет невыполненную работу, чтобы убедиться, что она содержит нужные элементы с приоритетом и что элемент в верхней части невыполненной работы готов. для выпуска или доставки.
Диаграмма Burndown: Диаграммы Burndown отслеживают количество выходных данных, выполненных командой в рамках проекта, на основе часов, элементов невыполненной работы или баллов.
Бизнес-гибкость : Это относится к способности компании или организации выявлять внутренние и внешние изменения и реагировать на них соответствующим образом, чтобы приносить пользу своим клиентам.
Каденция: Описывает поток событий согласно проекту. Cadence создает шаблон, которому команда может следовать, чтобы понять, что они делают.
Непрерывное улучшение : Это процесс повышения эффективности и качества путем постепенного внесения небольших изменений.
В структуре Канбан непрерывное совершенствование означает оптимизацию рабочего процесса и сокращение времени цикла, что повышает производительность.
Коллективное владение : Коллективное владение означает, что каждый член команды может изменить любой файл кода, будь то устранение дефекта, улучшение структуры кода или выполнение задачи разработки.
Epic: Epic — это большая история пользователя. В таком состоянии его было бы трудно выполнить за одну итерацию.
Fail-fast: Fail-fast описывает процесс начала работы над проектом, получения немедленной обратной связи, а затем принятия решения о продолжении работы над проектом или выборе другого подхода.
Итерация: Это фиксированный период времени, охватывающий от 2 до 4 недель, в течение которого Agile-команда создает готовый к поставке продукт.Владелец продукта определяет требования к итерации в начале итерации, и команда согласовывает их.
Канбан : Канбан позволяет Agile-команде записывать все о проекте на доске.
Это дает им лучшее понимание того, что происходит, и помогает им выявить узкие места, мешающие проекту.
Планирование игры в покер: Это игра или строительное упражнение, используемое для достижения группового консенсуса относительно приблизительной рабочей нагрузки.
Владелец продукта: Владелец продукта символизирует клиента и сообщает о видении и требованиях клиента команде Agile. Они записывают критерии приемки и ведут журнал невыполненных работ.
Scrum : Scrum — одна из самых популярных сред Agile. Он ориентирован на небольшие независимые команды, работающие над короткими спринтами (итерациями).
Скрам-мастер: Скрам-мастер — это член команды, который занимается общением между членами Скрам-команды и организует ежедневные встречи по планированию и ретроспективы.
Заинтересованное лицо: Это относится к тому, кто не является частью команды Scrum, но имеет некоторый интерес к продукту, созданному командой.
Спринты: Спринты — это короткие итерации, выполнение которых обычно занимает от 1 до 3 недель.
Задача: Задача определяет единицу работы, которая разбита на части пользовательской истории. Часто ее выполняет один член команды.
Доска задач: Это интерактивное или физическое визуальное представление пользовательских историй в виде задач.На доске также отображаются лица, которым назначена конкретная задача.
Технический долг: В процессе разработки проекта члены Agile-команды сталкиваются с рядом технических и эмоциональных проблем в личной жизни. Из-за этого команда иногда использует краткосрочный целесообразный подход к созданию продукта без учета долгосрочных последствий.
Разработка через тестирование (TDD): TDD — это практика создания и разработки тестов для функциональных рабочих кодов, а затем разработка кода, который пройдет эти тесты.Это помогает agile-команде понять весь потенциал и назначение кода, а также то, как он должен работать, еще до того, как он будет разработан.
Способы использования методологии AgileAgile направлен на создание более коротких циклов разработки и частых выпусков продуктов, в отличие от традиционного каскадного управления проектами. Из-за более коротких временных рамок команды могут более эффективно реагировать на изменения в потребностях клиентов. Тем не менее, методология Agile может помочь пользователям в следующем:
Проектное планированиеПрежде чем команды смогут начать какой-либо проект, им необходимо понять конечную цель, ценность клиента и то, как они будут выполнять проект.
Пользователи могут использовать структуру управления проектами Agile для создания области проекта. Тем не менее, они должны иметь в виду, что методология Agile направлена на внесение изменений и дополнений в проект более простым способом. Таким образом, масштаб проекта, который они разрабатывают, должен казаться изменчивым.
Создание дорожной карты продуктаДорожная карта продукта здесь относится к функциям, составляющим конечный продукт.
Дорожная карта является важным элементом этапа планирования Agile-проекта, поскольку команды разрабатывают отдельные функции во время каждого спринта/итерации.
На этом этапе владелец продукта также разрабатывает бэклог продукта. А когда план спринтируется позже, команда вытягивает задачи из бэклога.
Планирование выпускаВ управлении проектами Waterfall реализация даты обычно наступает после завершения всего проекта. Однако управление проектами Agile использует более короткие циклы разработки, что позволяет выпускать функции в конце каждого цикла.
Прежде чем приступить к проекту, владельцы проекта или команды могут составить качественный план выпуска новых функций после каждого спринта.Они всегда могут вернуться и переоценить выпуск той или иной функции.
Планирование спринтаПрежде чем начать спринт, заинтересованные стороны бизнеса должны сначала провести собрание по планированию спринта.
Это помогает им определить, что каждый член команды должен выполнить в течение этого спринта и как они это сделают. Равномерное распределение нагрузки между членами команды гарантирует, что во время спринта задача будет выполнена.
Заинтересованные стороны также могут визуально документировать рабочий процесс, чтобы выявлять и устранять узкие места, повышать прозрачность команды и делиться пониманием внутри команды Agile.
Ежедневные стендапыЕжедневные встречи помогают командам завершить свой проект во время каждого спринта и оценить внедрение необходимых корректировок. Эти встречи обычно длятся всего 15 минут. У каждого члена команды есть время, чтобы кратко объяснить, чего он добился накануне и что он будет делать в этот день.
Обзор спринта и ретроспективаК концу каждого весеннего цикла команда должна иметь функционирующую функцию или часть программного обеспечения.Если это так, заинтересованные стороны проекта проведут совещание по обзору спринта, на котором команда покажет им конечный продукт.
Кроме того, на этой встрече обе группы обсудят любые проблемы с продуктом, которые могут возникнуть.
На собрании ретроспективы спринта ключевые заинтересованные стороны обсудят, насколько эффективным был спринт, что можно было бы реализовать лучше и какие достижения были достигнуты в течение спринта.
Вся команда должна присутствовать на важных собраниях, особенно если они новички в управлении проектами Agile.Это помогает заинтересованным сторонам проекта оценить, может ли команда решить определенную задачу во время спринта, и определить продолжительность спринта для тематических проектов.
10 инструментов для гибкого управления проектамиКак и в случае с другими методологиями управления проектами, некоторые платформы лучше подходят для гибкого управления проектами, чем другие. Учитывая функциональность и возможности, вот список из 10 лучших инструментов управления проектами Agile:
Hive: идеальный инструмент для Agile-команд
Hive — ведущий инструмент управления проектами, используемый тысячами команд, включая тех, кто следует методологии управления проектами Agile.
Канбан-доски Hive делают его отличным инструментом гибкого управления проектами, поскольку они помогают визуализировать ход выполнения задач и информировать всех в режиме реального времени. Команды также могут использовать отслеживание времени для назначения оценок времени для отдельных задач, что очень полезно для планирования спринта и определения возможных следующих шагов. Интеграция Hive с масштабированием и функции Notes упрощают виртуальную совместную работу на собраниях в Hive. Это упрощает для команд проведение эффективных ежедневных схваток и совещаний по планированию спринта.
Хотите попробовать Улей самостоятельно? Подпишитесь на бесплатную 14-дневную пробную версию, чтобы узнать, как Hive может помочь вашей гибкой команде повысить производительность и работать быстрее уже сегодня.
ЗаключениеAgile Methodology — это эффективный и отличный процесс для команд и организаций, которые ищут гибкий подход к разработке продукта. Что еще лучше, так это то, что это не ограничивается отраслями разработки программного обеспечения; его может внедрить любая организация или бизнес, которым нужен нелинейный план, эффективная командная работа, сотрудничество с клиентами и качественные результаты.
11 лучших инструментов Scrum для гибкого управления проектами в 2022 году
За последние несколько лет методология Scrum стала одной из основных основ гибкого управления проектами. И это неудивительно: со Scrum процесс управления вашим проектом становится более гибким и прозрачным, при этом риски ниже, а удовлетворенность клиентов ставится на первое место.
Однако успешное и эффективное гибкое управление проектами — далеко не самая простая задача.Между ежедневными встречами, мониторингом задач и расстановкой приоритетов иногда трудно сосредоточиться на том, что важно.
Вот где в игру вступают инструменты Scrum для гибкого управления проектами. Из-за растущей популярности методологии Scrum многие новые компании разрабатывают и предлагают инструменты Scrum.
Чтобы помочь вам не потеряться в этом изобилии и лучше понять, какой инструмент Scrum лучше всего подойдет для вашего проекта, в этой статье мы рассмотрим 11 лучших инструментов, которые вы должны попробовать в 2022 году.
Давайте начнем!
Jira от Atlassian — один из самых известных инструментов гибкого управления. Это отличный вариант управления Agile-проектами для компаний, занимающихся ИТ и разработкой программного обеспечения, а также для крупных бизнес-организаций.
Jira поставляется с тысячами функций, таких как доски Scrum, настраиваемые невыполненные работы, параметры отчетности и многие другие. Можно с уверенностью сказать, что Jira поставляется со всеми инструментами, которые могут понадобиться вашей команде во время работы. Однако это большое количество инструментов делает Jira сложным механизмом освоения, который может быть сложным и непосильным для новичков.
Ключевые функциональные возможности:- Настраиваемые рестораны отчетов
- Настраиваемые Scrum Dashboards
- Гибкие kanban Board
- Расширенные варианты безопасности
- Управление ошибками
- Опции поиска и фильтрации
- Инструменты для создания дорог
Платные планы начинаются с 7 долларов США в месяц на пользователя и далее растут.
Также доступна бесплатная версия с ограниченным функционалом.
Список инструментов Scrum не может быть полным без упоминания Trello, одного из наиболее широко используемых инструментов управления задачами и проектами во всем мире.Trello — это наглядный и простой способ увидеть, что нужно сделать. Это простой и быстрый способ организовать и повысить производительность команды, созданный для команд любого размера. Благодаря своей универсальности, огромному количеству инструментов разного назначения и возможностей настройки, Trello — отличный инструмент для разных проектов и направлений, от разработки программного обеспечения до рекрутинговых и маркетинговых проектов. Независимо от того, разрабатываете ли вы новое программное обеспечение или организуете управление социальными сетями или кампанию по электронной почте, вы можете использовать этот инструмент для лучшей организации процесса.
Основным недостатком Trello является то, что при работе в больших группах количество карточек иногда может быть огромным.
По мере роста команды и количества задач это может стать проблемой, требующей внимания.
Итак, что вы можете сделать вместе с Trello, чтобы повысить эффективность? Чтобы упростить этот процесс, рассмотрите возможность создания стратегии реферального маркетинга. Это поможет сделать ваш бизнес более узнаваемым и любимым клиентами.
Основные характеристики- Простое перетаскивание редактирования карты
- Запись карты
- Card Records Archive
- Контрольные списки Для каждой карты
- Отчет о ходе работы
- Приоритетные задачи и сроки
- Файловые вложения
- Теги и этикетки для систематизации
- Цвета карточек и обложки для облегчения совместной работы
Доступен бесплатный вариант с ограниченной функциональностью.Платные варианты начинаются с 10 долларов в месяц на пользователя при годовой подписке.
Sprints от Zoho — это облачный инструмент Scrum для планирования и отслеживания проектов. Инструмент был разработан с учетом гибкой методологии и прост в использовании. Zoho Sprints невероятно удобен в использовании и не требует много времени для начала работы.
Несмотря на свою простоту, Zoho предлагает все необходимые гибкие инструменты для планирования и успешного выполнения ваших проектов. Используйте его, чтобы назначать задачи, назначать встречи, планировать свой контент, создавать информационные панели и невыполненные работы, а также помогать другим рабочим процессам Scrum.Чтобы сделать процесс более эффективным, убедитесь, что вы выражаете признательность и мотивируете своих сотрудников держать всех на одном пути.
С другой стороны, это может быть не самый эффективный инструмент для крупных компаний и предприятий. Инструмент поддерживает только до 500 пользователей и может не иметь некоторых важных функций, которые нужны более крупным командам.
Основные характеристики: Особенности:- Настраиваемые Scrum Boards
- Центр планирования перетаскивания
- пользовательских заданий
- пользовательских приоритетов
- Оценка оценки
- Отчетность
- Сроки состояния
- Google Drive и Zendesk Extensions
Доступен бесплатный план для пяти пользователей и пяти проектов.Платные планы начинаются с 12 долларов в месяц для 12 пользователей (при оплате ежегодно), а затем меняются в зависимости от количества пользователей в компании.
Active Collab — это универсальный инструмент для гибкого управления проектами, разработанный для творческих профессионалов. Помимо основных функций инструментов Scrum, таких как добавление и назначение задач, доступны различные другие инструменты. Независимо от того, работаете ли вы над мобильным приложением или дизайном программного обеспечения, управляете технологической компанией или только начинаете онлайн-бизнес, вы можете использовать Active Collab для составления списков и обсуждений, управления финансами проекта, отслеживания рабочего времени и параметров отчетности, а также для просмотра задачи в виде календаря, досок или списков.
Помимо встроенных функций, Active Collab поставляется с большим выбором надстроек, которые вы можете интегрировать в свое рабочее пространство. Миграция с других инструментов Scrum также упрощается: вы можете импортировать задачи из Asana, Trello, Wrike и другого программного обеспечения для управления проектами.
Основные характеристики: 9- Функции присоединения к файлам
- Task Time Recorder
- расходы калькулятор трек
- ДЕЯТЕЛЬНОСТЬ ДЕЯТЕЛЬНОСТЬ
- Обсуждение
- Milestone Preview
- Счет-фактура Создатель и управление
- Индивидуальный список задач
- Просмотр календаря
- Варианты отчетов
- Контактная информация
Active Collab бесплатен для трех пользователей, предлагая ограниченные функции.Платный план начинается с 7,5 долларов США в месяц для трех участников при ежегодной оплате.
Еще одним в нашем списке инструментов управления проектами Scrum является Scrumwise, простой и интуитивно понятный инструмент, который позволяет вам сосредоточиться на ключевых частях вашего проекта.
Если вы ищете полный инструмент для работы с вашей методологией Scrum без дополнительной суеты, Scrumwise может быть именно тем, что вы ищете. Упростите управление задачами, разбив задачи на контрольные списки и отслеживая процент выполнения, чтобы всегда знать, на каком этапе находится ваш проект.
Scrumwise обладает всеми функциями, необходимыми для удовлетворения потребностей команды разработчиков. Он позволяет вам визуализировать свою работу и точно знать, где вы находитесь в любой момент, упорядочивать невыполненные работы и использовать доски Канбан для отслеживания задач. С помощью Scrumwise вы всегда можете иметь общее представление о вещах. Вы также можете разделить задачи на управляемые части и отслеживать процент выполнения, чтобы знать, где находится ваш проект в данный момент.
Однако, если вы ищете инструмент, который имеет интеграцию с часто используемыми командами разработчиков инструментами, такими как Confluence и Slack, Scrumwise может оказаться не лучшим вариантом для вашей команды.
Основные характеристики:- Timeline View
- Инструменты для совместной работы
- Отслеживание прогресса
- Опции отчетов и аналитики
- ОБОРУДОВАНИЯ ДАННЫХ
- Управление ресурсами
- Диаграмма Burndown
- Управление на выпуске
- Настройка
Бесплатный план недоступен, но Scrumwise предлагает 30-дневную бесплатную пробную версию. Затем вы можете подписаться по цене 7,5 долларов США в месяц за пользователя с ежегодной оплатой.
ClickUp — это облачный инструмент для совместной работы и повышения производительности, который помогает организовать всю вашу работу в одном месте. Тысячи интеграций, таких как Trello, Slack, Microsoft Outlook, Asana, Gmail, Todoist и многие другие, позволяют вам иметь все в одном приложении.
ClickUp также является отличным способом организации рабочего процесса Scrum, поскольку позволяет назначать задачи и расставлять приоритеты, устанавливать крайние сроки, создавать временные рамки, создавать настраиваемые представления для каждого пользователя и видеть, как работает ваша команда.Если вы часто используете документы и электронные таблицы в своей работе, ClickUp может стать для вас инструментом: создавайте и делитесь ими прямо из приложения. Инструмент также реализует ИИ для анализа и информирования пользователей о том, над чем им нужно работать дальше, отправляя им напоминания и уведомления, чтобы они не отставали.
Однако, как и в случае с Jira, из-за своей универсальности ClickUp может быть трудным для освоения новичками, что приводит к плоской кривой обучения. Еще один недостаток ClickUp заключается в том, что он очень ориентирован на задачу, и вы не можете отслеживать производительность на уровне проекта.
Основные характеристики: Особенности:- Инструменты управления задачами
- Каналы внутренних коммуникаций
- Проектные каналы и управленческие решения
- Настраиваемые приборные панели
- Параметры автоматизации для ручных задач
- Отчеты
- Огромные варианты интеграции
Доступен бесплатный план с ограниченным объемом памяти и функциями. Безлимитный план начинается с 5 долларов США в месяц за пользователя, оплачиваемого ежегодно.
Еще один инструмент управления проектами, основанный на философии Scrum, — Monday.com. Простой, но универсальный инструмент, который подходит для всех команд компании, от отдела кадров до разработки программного обеспечения.
Как и другие инструменты Scrum, Monday.com предлагает широкий выбор функций для назначения и управления задачами вашей команды. Несколько вариантов просмотра позволяют менеджерам видеть, какая задача назначена кому, из какой команды, а также приоритет и оценку времени. Вы можете прикрепить файлы документов к каждой задаче, чтобы все было доступно.
Доступна интеграция с тысячами приложений, таких как Facebook, Shopify, MailChimp, Slack, Microsoft Excel, Todoist и многими другими, поэтому командам не нужно переключаться между инструментами и оставаться сосредоточенными.
С другой стороны, управление доской в Monday.com сложнее, чем в случае с другими инструментами. Перемещение досок, их связывание и настройка далеко не беспроблемны и могут потребовать больше времени, чем следовало бы.
Основные характеристики:- тысячи вариантов интеграции
- файл вложения
- Маркировка и категоризация
- Оценка задачи
- Оценка заданий
- Оценка приоритета
- Опции отчетности
- Варианты настройки
- Возможности совместной работы между командами
Понедельник.com предлагает бесплатный план для двух человек. Платные планы начинаются с 8 долларов в месяц за рабочее место, до 24 долларов в месяц при ежегодной оплате.
Если вы ищете гибкий инструмент для управления проектами, который поможет вам справиться с операционными проблемами, с которыми сталкивается ваша компания, тогда QuickScrum может быть ответом. QuickScrum, созданный для помощи в управлении проектами и ресурсами, увеличении доходов и успешном привлечении клиентов, представляет собой удобный инструмент, который может упростить работу вашей компании и повысить производительность.
QuickScrum — это простой инструмент, для начала работы с которым не потребуется много времени. Канбан-доски с простыми функциями перетаскивания упрощают планирование спринтов и управление ими. Используйте диаграммы скорости и выгорания для отслеживания еженедельного и ежемесячного прогресса. Добавляйте комментарии к задачам, чтобы всегда быть на одной волне со своей командой и ускорить выполнение проекта.
QuickScrum также предлагает онлайн-сессии адаптации и руководство по использованию продукта, чтобы помочь вашей команде внедрить продукт.
Основные характеристики: Особенности:- РАСПРЕДЕЛЕННЫЕ ИСПОЛЬЗОВАНИЯ
- Продукт и дефекты Обленты
- Спринт Планирование и управление
- Обзоры
- Обзоры команды
- Команда Обзоры и ретроспекции
- Управление файлами
- Ежедневная и долгосрочная отчетность
- Защита данных
Стоимость QuickScrum составляет 5 долларов США в месяц на пользователя при годовой оплате.Доступна 14-дневная бесплатная пробная версия.
Yodiz — один из самых всеобъемлющих, но интуитивно понятных инструментов Scrum, который вы можете выбрать. Он поставляется с подробным списком функций, которые позволяют вам эффективно управлять всеми частями вашего проекта для успешного результата.
С Yodiz вы можете управлять своими задачами, спринтами, невыполненными работами, отчетами и выпусками из одного места. Вы можете ставить и маркировать задачи по их срочности, чтобы ваша команда знала, что нужно сделать и в какие сроки. Затем вы можете использовать диаграммы Burndown, чтобы лучше понять, что еще нужно сделать, и соответствующим образом распределить время и ресурсы.Разнообразные диаграммы и варианты отчетов позволяют легко следить за ходом проекта и команды.
Основные характеристики:- Sprint Management
- Настраиваемые канбанские доски
- Reporting и Burndown Charts
- задача Приоритеты и даты
- Комментируя и метки
- Мобильные приложения для iOS и Android
Доступен бесплатный план для трех пользователей с неограниченными возможностями.Затем платные планы начинаются с 3 долларов в месяц на пользователя и растут в зависимости от необходимых вам функций.
ScrumDo — это популярный гибкий инструмент, предлагающий решения рабочего процесса Scrum, который в первую очередь оценят команды, которые делают упор на данные и статистику.
Расширенные возможности статистики и отчетности позволяют отслеживать эффективность проекта с разных точек зрения. Эти инструменты включают, среди прочего, диаграммы выгорания и выгорания, гистограммы и блок-схемы. С инструментами визуального управления ScrumDo вы всегда будете знать, где находится ваш проект в данный момент, и получите представление о том, что следует расставить по приоритетам.
Основные характеристики:- Kanban revbards
- Smart Learts
- Management Management
- BackLog Management
- Сотрудничество и время отслеживания
- Приоритетность и планирование времени
- Управление проектом
- Tracking Cass
- Daily Reports
После семидневной бесплатной пробной версии вы можете начать использовать ScrumDo за 8,99 долларов США в месяц для 10 пользователей. Затем цены растут в зависимости от размера вашей команды.
nTask — один из самых интуитивно понятных и простых в использовании инструментов scrum, используемых в управлении проектами. Используя эту платформу, вы можете управлять своими проектами от начала до конца, чтобы обеспечить управление эффектами в нескольких рабочих процессах.
Эта платформа поможет вам управлять задачами, проектами, расписаниями, рисками, отслеживанием проблем и управлением собраниями в одном месте. Вы можете не переключаться между приложениями для управления разными проектами и назначать работу членам команды всего за несколько кликов.Чтобы отслеживать прогресс, используйте интерактивные диаграммы Ганта с функцией перетаскивания и используйте доски Канбан для визуализации рабочего процесса.
Интегрируйте свое любимое приложение с nTask, включая Google Calendar, Zoom, Slack, Zapier, iCal и многие другие. Вы можете легко адаптироваться к этой платформе и использовать готовые шаблоны для начала работы.
Основные характеристики:- Управление документами и обмен файлами
- Назначение задач
- Оценка времени и автоматическое отслеживание времени
- Пользовательские поля и приоритизация
- Просмотр списка, просмотр доски, просмотр календаря и Ганта
- Мобильные приложения для iOS и Android
Бесплатный план доступен для 5 пользователей с неограниченным количеством задач.Премиум-план стоит 2,99 доллара в месяц для каждого пользователя, а бизнес-план с дополнительными настройками — 7,99 доллара в месяц для каждого пользователя.
Подведение итоговИспользование правильного гибкого инструмента управления проектами может привести к успеху или провалу вашего проекта. В начале вашего проекта посвятите некоторое время тому, чтобы понять свои потребности, а затем попробуйте несколько инструментов, чтобы найти правильный. Хотя это может показаться большим усилием, вы увидите влияние своего выбора позже.
Что такое гибкое управление проектами? И может ли это помочь вашему бизнесу? – Советник Forbes
Примечание редакции. Мы получаем комиссию за партнерские ссылки в Forbes Advisor.Комиссии не влияют на мнения или оценки наших редакторов.
Как предприниматель, вы, вероятно, проводите свой день, пытаясь поразить все виды движущихся целей. Ваш клиент хочет одно в понедельник и другое в среду. Новые появляющиеся технологии или конкуренты заставляют вас вносить коррективы. Попасть в движущуюся цель было бы намного проще, если бы вы могли корректировать выстрел после нажатия на спусковой крючок.
избранных партнеров
бесплатная версия
бесплатная версия
да
YES
от $ 10 ежемесячно на пользователя
интеграции
Zoom, LinkedIn, Adobe, Salesforce и более
бесплатная версия
Да
Начальная цена
От $9.80 Ежемесячно на пользователя
Интеграция Доступна
Google Drive, Microsoft Office, Dropbox и MOR MOLE
Бесплатная версия Доступна
Да
Начальная цена
от $ 4 Ежемесячные на пользователя
Интеграция Доступна
Github, Bitbucket, Crashlytics
Войдите в Agile-управление проектами.
Гибкое управление проектами — популярная методология для отслеживания различных ролей, обязанностей, сроков и других факторов проекта.При правильном использовании Agile может сэкономить организациям много времени, разочарований и денег. Вот как это работает.
Что такое Agile?
Agile — это итеративная, интроспективная и адаптивная методология управления проектами. В Agile-практике проект разбивается на подпроекты. Обычно их называют спринтами. В конце каждого спринта заинтересованные стороны и команда анализируют свою работу, вносят коррективы для следующего спринта и повторяют до завершения. Суть Agile заключается в постоянной, постепенной доставке ценности на протяжении всего проекта, а не сразу в конце.
Гибкое управление проектами уходит своими корнями в разработку программного обеспечения. Циклы разработки теперь намного короче, чем раньше. Разработчикам программного обеспечения могут потребоваться годы, чтобы вывести продукт на рынок. В некоторых случаях программное обеспечение устаревало еще до того, как попадало в руки потребителей.
Частично виноваты традиционные структуры управления проектами. Они очень жесткие и линейные. Трудно адаптироваться к возникающим проблемам, и ничего не высвобождается, пока вся работа не будет завершена.
Платформа решает многие бизнес-проблемы, охватывая хаос. Он разработан с учетом того, что вы столкнетесь с неожиданными проблемами. Он знает, что вам неизбежно придется внести изменения, чтобы достичь желаемого результата.
Agile позволяет вашей команде выбрать общее направление, построить что-то, а затем переоценить ситуацию. Многие команды как в индустрии программного обеспечения, так и за ее пределами находят этот подход полезным при выполнении сложных задач.
Гибкое управление проектами: пример
Допустим, вы создаете приложение. Владелец продукта получает информацию от стейкхолдеров. Это могут быть руководители, клиенты или и те, и другие. Они говорят что-то вроде: «Нам нужно приложение, в котором пользователи смогут создавать и продавать виджеты друг другу». Из этих взаимодействий владельцы продукта создают бэклог. Бэклог — это список всех задач, которые необходимо выполнить для достижения общей цели.
Далее команда проводит предспринтерское совещание.Они просматривают невыполненную работу и определяют, какой объем работы они могут взять на себя. Как только они берутся за работу и делят ее между собой, начинается спринт. Спринт обычно занимает несколько недель, но не более месяца. В начале каждого дня команда собирается на стендап-митинг. Они короткие, все встают (чтобы встреча была короткой), и вы анализируете работу предыдущего дня и вносите коррективы, если это необходимо.
В конце спринта команда и заинтересованные лица анализируют прогресс, фиксируют свою работу, вносят коррективы для следующего спринта и повторяют.Так продолжается до тех пор, пока не будет достигнута основная цель.
В общем, Agile — это разбиение сложных задач на простые спринты. При правильном использовании они могут иметь огромное значение для продуктивности и морального духа вашей команды.
Agile-манифест
Как и большинство великих теорий, Agile представлена в виде манифеста. Здесь авторы Манифеста для гибкой разработки программного обеспечения (широко известного как Манифест Agile) определяют четыре основные ценности и 12 принципов гибкого управления проектами.
Гибкое управление проектами требует тесного сотрудничества, гибких команд, которые могут обеспечивать постоянную ценность на каждой итерации. Это имеет смысл, учитывая, что Agile по своей сути интроспективен и ориентирован на постоянную тонкую настройку для оптимизации результатов.
Четыре основных ценности гибкого управления проектами
Четыре основные ценности Agile включают:
- Индивиды и взаимодействие через процессы и инструменты
- Рабочее программное обеспечение поверх исчерпывающей документации
- Сотрудничество с клиентами по поводу переговоров по контракту
- Реагирование на переход по плану
12 принципов гибкого управления проектами
12 принципов методологии основаны на этих ценностях, согласно Agile Manifesto:
- Наивысшим приоритетом является удовлетворение клиента за счет быстрой и непрерывной поставки ценного программного обеспечения.
- Приветствуйте изменяющиеся требования, даже на поздних стадиях разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
- Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, отдавая предпочтение более коротким временным рамкам.
- Деловые люди и разработчики должны ежедневно работать вместе над проектом.
- Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
- Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
- Работающее программное обеспечение является основным мерилом прогресса.
- Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
- Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
- Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
- Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
- Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Различные виды гибких методологий управления проектами
Генеалогическое древо Agile методологий управления проектами имеет много ветвей. Все теории управления проектами Agile придерживаются основных принципов Agile, но делают это немного по-разному.Мы не будем останавливаться на всей семье здесь. Но мы обсудим два самых популярных варианта Agile.
Скрам
Основатели Scrum определяют его как «облегченную структуру, которая помогает людям, командам и организациям создавать ценность за счет адаптивных решений сложных проблем». Скрам основан на идеях, которые мы учимся в процессе работы, потери должны быть сведены к минимуму, и мы должны сосредоточиться на самом важном. Scrum следует использовать против команды игроков с несколькими инструментами, которые коллективно создают приращения ценности на каждой итерации.
В Scrum-практике Scrum-команда состоит из владельца продукта, Scrum-мастера и команды разработчиков. Владелец продукта отвечает за максимизацию ценности конечной цели, а скрам-мастер отвечает за поддержание скрама и получение максимальной отдачи от команды разработчиков. Команда разработчиков работает.
Scrum — самый популярный метод Agile. Согласно результатам опроса, представленным в 14th Annual State of Agile Report, 75% респондентов заявили, что практикуют Scrum или Scrum-гибрид.
Канбан
Канбанопирается на визуализацию и элементы управления для отслеживания рабочей нагрузки и управления ею. Базовая канбан-доска состоит из трех столбцов: «Запрос», «Выполняется» и «Готово». Но многие компании создают столбцы для каждого шага рабочего процесса.
Каждый проект визуализируется в виде карточек на канбан-доске и продвигается по каждому столбцу, пока работа не будет завершена. Ограничение «незавершенное производство» (WIP) создается и применяется к каждому столбцу, чтобы не допустить, чтобы команда слишком напрягала себя, выполняя слишком много работы.Оттуда необходимо поддерживать устойчивый, устойчивый темп и при необходимости корректировать процессы для оптимизации.
По данным 14th State of Technology, 63% респондентов заявили, что используют Канбан в своих организациях.
Используйте Agile в своей среде
Гибкое управление проектами не является универсальной методологией. Эффективность Agile зависит от целей, которых вы пытаетесь достичь. Если вы стреляете по стационарной цели и не можете отклониться от заданного пути, Agile может быть не лучшим выбором.Но если вы пытаетесь поразить движущуюся цель и вам нужно максимально эффективно использовать время и ресурсы, имеющиеся в вашем распоряжении, Agile может стать решением ваших проблем.
Люди в вашей команде также должны учитываться перед внедрением Agile. Согласно отчету State of Agile Report, культура и заинтересованность имеют большое значение, а неправильная культура и отсутствие заинтересованности являются основными причинами провала Agile. Но что еще более важно, люди являются центральным компонентом Agile. Вам нужна команда многофункциональных игроков, которые могут работать вместе, адаптироваться к изменениям и оставаться сосредоточенными на цели.
Если вы решите, что Agile не подходит для вашей команды, рассмотрите возможность внедрения одной из других методологий управления проектами.
Часто задаваемые вопросы
Подходит ли Agile только для разработки программного обеспечения?
Нет. Другие добились успеха с Agile — или, по крайней мере, с использованием определенных компонентов Agile — за пределами разработки программного обеспечения. Люди в автомобильной, научно-исследовательской и других отраслях добились успеха в Agile. Стоячие встречи распространены в самых разных рабочих средах, от ресторанов до залов заседаний.Канбан-доски появляются повсюду, например, на досках в юридических конторах и на окнах в офисах по управлению недвижимостью.
Существуют ли сертификаты для гибкого управления проектами?
Да. Вы можете получить сертификаты управления проектами Agile в различных аккредитованных колледжах и университетах, а также в профессиональных и торговых организациях.
Нужно ли мне покупать инструмент управления проектами, чтобы внедрить Agile-управление проектами в свой бизнес?
Вам не нужно приобретать специализированные решения для управления проектами Agile, чтобы развернуть или добиться успеха с Agile.Однако существует множество решений для управления проектами, которые могут расширить, дополнить и улучшить вашу практику Agile.
Agile-управление проектами с помощью Scrum
Abstract
Scrum — это одна из гибких методологий, предназначенных для руководства командами при итеративном и поэтапном выпуске продукта. Часто называемая «гибкой структурой управления проектами», ее основное внимание уделяется использованию эмпирического процесса, который позволяет командам быстро, эффективно и действенно реагировать на изменения.Традиционные методы управления проектами фиксируют требования, чтобы контролировать время и затраты; Scrum, с другой стороны, фиксирует время и стоимость, чтобы контролировать требования. Это делается с помощью временных рамок, совместных церемоний, приоритетного невыполненной работы по продукту и частых циклов обратной связи. Участие бизнеса на протяжении всего проекта имеет решающее значение, поскольку Scrum в значительной степени зависит от сотрудничества между командой и клиентом или представителем клиента для создания правильного продукта с минимальными затратами.В этой статье представлен обзор Scrum и его использования в управлении проектами.
Что такое Скрам?
Сначала мы должны четко определить, чем не является Scrum. Существует распространенное заблуждение, что Agile — это Scrum. Хотя Scrum действительно гибок, это не единственный метод реализации agile-принципов. Scrum — это просто один из многих гибких подходов к разработке продукта. Другие методы включают экстремальное программирование (XP), Crystal, Feature Driven Development, DSDM Atern и так далее. Все эти методы соответствуют Agile Manifesto и связанным с ним принципам.Полезной метафорой было бы думать об Agile как о мороженом, в то время как Scrum, XP, Crystal и т. д. — это просто разные вкусы, такие как шоколад, клубника, ваниль. Все они гибкие, все хороши, и многие из них можно использовать в комбинации.
Проще говоря, Scrum — это гибкий метод итеративной и поэтапной доставки продукта, который использует частую обратную связь и совместное принятие решений.
История
Scrum основан на статье 1986 года, написанной Хиротакой Такеучи и Икудзиро Нонакой для Harvard Business Review под названием «Новая игра в разработку нового продукта.В этой статье авторы использовали регби в качестве метафоры для описания преимуществ самоорганизующихся команд в разработке и доставке инновационных продуктов. Джефф Сазерленд, Кен Швабер и Майк Бидл взяли идеи из этой статьи, включая метафору, и применили их к своей области разработки программного обеспечения. Свой новый метод они назвали Scrum, в честь термина из регби, который описывает, как команды образуют круг и идут за мячом, чтобы снова вернуть его в игру. Они впервые применили этот метод в Easel Corporation в 1993 году.Швабер и Бидл написали о своем опыте в своей книге Agile Software Development with Scrum в 2002 году, а затем в книге Швабера Agile Project Management with Scrum в 2004 году, которая включала работу, проделанную Швабером с Primavera.
Scrum Framework
Schwaber называет Scrum фреймворком, а не методологией. В первую очередь это связано с коннотациями слова «методология», которые многие считают предписывающими по своей природе. В отличие от этого, Scrum просто предоставляет структуру для доставки, но не говорит вам, как выполнять конкретные действия, оставляя это на усмотрение команды.На рисунке 1 показана базовая структура Scrum.
Приложение 1. Первоначальная структура Scrum
Проект начинается с четкого видения, предоставленного бизнесом, и набора функций продукта в порядке их важности. Эти функции являются частью списка невыполненных работ по продукту, который поддерживается заказчиком или представителем заказчика, именуемым владельцем продукта. Временной интервал, обычно называемый итерацией или спринтом, представляет собой установленное количество времени, в течение которого команда должна выполнить выбранные функции.Спринты обычно длятся от одной до четырех недель, и эта продолжительность сохраняется на протяжении всего жизненного цикла проекта, чтобы установить ритм. Команда выбирает элементы из бэклога продукта, которые, по ее мнению, могут быть выполнены в течение спринта, и создает бэклог спринта, состоящий из функций и задач, в рамках совещания по планированию спринта.
После того, как команда определилась с невыполненной задачей спринта, начинается работа над задачей. В течение этого времени в спринте команда защищена от прерываний и может сосредоточиться на достижении цели спринта.Никакие изменения в бэклоге спринта не допускаются; однако бэклог продукта можно изменить при подготовке к следующему спринту.
Во время спринта команда ежедневно проверяет друг друга в форме 15-минутной встречи, известной как схватка. Команда становится в круг, и каждый участник рассказывает, что он сделал вчера, что планирует сделать сегодня и что ему мешает.
В конце спринта команда демонстрирует выполненную работу заинтересованным сторонам и собирает отзывы, которые повлияют на то, над чем они будут работать в следующем спринте.Они также проводят ретроспективу, чтобы узнать, как стать лучше. Эта встреча имеет решающее значение, поскольку она посвящена трем столпам Scrum: прозрачности, проверке и адаптации.
Роли и обязанности
В Scrum всего три роли: скрам-мастер, владелец продукта и команда.
Скрам-мастер — хранитель процесса, защитник и защитник команды. Они устраняют препятствия, облегчают общение в команде, участвуют в дискуссиях внутри команды и ведут переговоры с внешними по отношению к команде людьми.Прежде всего, они существуют в служении команде.
Владелец продукта представляет голос клиента и имеет право принимать решения о продукте. Этот человек владеет бэклогом продукта и отвечает за передачу видения команде, а также за определение и приоритизацию элементов бэклога. Владелец продукта ежедневно работает с командой, отвечая на вопросы и предоставляя рекомендации по продукту.
Команда состоит из семи плюс-минус двух человек, которые несут совместную ответственность за доставку продукта.Они владеют оценками, берут на себя обязательства по задачам и сообщают друг другу о ежедневном статусе в ежедневной схватке. Они самоорганизуются, то есть структура появляется без явного вмешательства извне. Другими словами, команда владеет тем, как она решает создавать функции продукта — команда владеет тем, «как», а владелец продукта владеет тем, «что».
Применение Scrum
Scrum применяется путем проведения ряда церемоний или собраний. Обязательные церемонии Scrum включают собрание по планированию спринта, ежедневный скрам, обзор спринта и ретроспективу спринта.Также требуется работа в таймбоксах, называемых спринтами. Совещания по планированию выпуска являются необязательными и позволяют планировать и прогнозировать группы спринтов.
Совещание по планированию спринта
Совещание по планированию спринта проводится в первый день каждого спринта. Присутствуют скрам-мастер, владелец продукта и команда. Владелец продукта представляет набор функций, которые он или она хотели бы видеть завершенными в спринте («что»), после чего команда определяет задачи, необходимые для реализации этих функций («как»).Оценки работы проверяются, чтобы увидеть, есть ли у команды время для завершения всех функций, запрошенных в спринте. Если это так, команда совершает спринт. Если нет, функции с более низким приоритетом возвращаются в бэклог продукта до тех пор, пока рабочая нагрузка для спринта не станет достаточно малой, чтобы получить обязательство команды.
Отслеживание прогресса
После того, как собрание по планированию спринта завершено и команда приняла на себя обязательства, команда начинает отслеживать свой прогресс, используя хорошо видимые информационные излучатели.Эти излучатели включают диаграмму выгорания и доску задач.
Доска задач используется командой для отслеживания хода выполнения задач по каждой функции. Минимальные используемые столбцы: To Do, Doing и Done. Команды будут проводить свои ежедневные схватки у доски задач и перемещать элементы по доске, сообщая, что они сделали вчера, что они планируют сделать сегодня и с какими препятствиями они борются. См. Приложение 2 для примера доски задач для проекта разработки программного обеспечения.
Приложение 2.Пример доски задач Scrum (Графика предоставлена Mountain Goat Software. Все права защищены.)
На диаграмме выгорания показана линия тренда объема работы, которую осталось выполнить в спринте. Ось X — это количество дней в спринте, а ось Y — это количество часов для всех задач, которые были определены на собрании по планированию спринта. В течение дней спринта линия, показывающая объем оставшейся работы, должна стремиться к нулю к последнему дню спринта. См. Приложение 3 для примера диаграммы выгорания спринта.
Приложение 3. Пример диаграммы выгорания спринта
Ход выполнения спринта отслеживается с помощью диаграммы выгорания, доски задач и ежедневного скрама. В сочетании эти три вещи могут дать четкое представление о том, над чем работают, что завершено, что еще предстоит сделать, будет ли это завершено вовремя, и что может помешать команде выполнить свой спринт и/или освободить цель.
Обзор спринта
В конце спринта команда приглашает заинтересованные стороны на собрание по обзору спринта, на котором демонстрируются функции, реализованные в спринте, и запрашивается обратная связь.Владелец продукта отслеживает отзывы и по мере необходимости включает их в бэклог продукта.
После завершения обзора команда (без заинтересованных сторон) проводит ретроспективу, чтобы определить, что они сделали хорошо, что они хотели бы продолжать делать, с чем они столкнулись, и какие у них есть рекомендации по изменениям в будущем. Создается план действий, и эти элементы реализуются в течение следующего спринта, а их эффективность проверяется в ретроспективе следующего спринта.
Планирование релиза
Планирование релиза также является частью Scrum и является способом долгосрочного планирования на временной интервал, состоящий из нескольких спринтов. Это часто делается ежеквартально, и результаты квартала не обязательно должны быть выпуском для клиента, а могут быть просто внутренним выпуском для подтверждения системной интеграции и проверки. На рис. 4 показано, как планирование релиза согласуется с остальной частью фреймворка Scrum.
Вся команда присутствует на совещании по планированию релиза, где Владелец Продукта представляет функции, которые он/она хотел бы видеть завершенными в этом квартале.Однако команда не выделяет эти функции, а вместо этого предоставляет общие оценки уровня, чтобы определить, какие функции могут быть выполнены в каком спринте и сколько из этих функций может быть завершено к концу квартала. Планирование релиза может быть ориентировано на функции (сколько спринтов потребуется для завершения этого набора функций?), на время (сколько функций мы можем ожидать завершить к этому сроку?) или на затраты (учитывая этот бюджет, как выглядит наш график и какие функции мы будем делать до того, как у нас закончатся деньги?).
Приложение 4. Планирование релиза в Scrum
Некоторые примеры Scrum
Scrum широко используется в проектах разработки программного обеспечения, и с помощью простого поиска в Google можно найти множество примеров. Что менее очевидно, так это использование Scrum в проектах, не связанных с программным обеспечением, поэтому некоторые из этих примеров приведены ниже.
Написание книги с использованием Scrum
Моя коллега Стасия Вискарди и я использовали Scrum для управления нашим книжным проектом. Наше портфолио продукта состояло из глав, которые мы хотели написать для «Мост руководителя проекта программного обеспечения к гибкости », в порядке приоритета на основе запросов клиентов.Например, из-за того, что мы получили много вопросов об управлении содержанием и очень мало вопросов о закупках, глава, посвященная содержанию, оказалась в верхней части невыполненной работы, а глава о закупках — ближе к концу.
Мы провели совещание по планированию релиза и переместили элементы невыполненной работы на страницы флипчарта, которые представляли наши спринты продолжительностью в один месяц. В начале каждого спринта мы созванивались, чтобы обсудить главы, которые мы будем писать, установить цели и ожидания и принять обязательства.Во время спринта мы проверяли друг друга несколько раз в неделю. Когда мы завершали главы в спринте, мы обменивались ими, чтобы получить обратную связь, а затем включали эту обратную связь в окончательный вариант. Наши обзоры спринта состояли из окончательного обзора глав, и любые дополнительные изменения оказывались в бэклоге продукта, который планировался в следующем спринте.
Поскольку мы были только вдвоем, мы поменялись ролями и обязанностями. В одном разделе книги меня называли владельцем продукта, и я обладал полномочиями на окончательную функцию.В других разделах эта роль была у Стасии. Наш скрам-мастер был нашим редактором, хотя и не осознавал этого. Он по-прежнему выполнял обязанности скрам-мастера, однако напоминал нам о наших сроках, устранял для нас препятствия и давал нам помощь и инструменты, необходимые для выполнения нашей работы.
И не только мы используем Scrum для написания книг. Lonely Planet использует Scrum при разработке своего путеводителя: «До Scrum разработка книги была очень последовательной и требовала многократных передач, и требовалось много времени, чтобы вывести книгу от концепции до публикации.Теперь они привлекают всех участников, необходимых для создания книги (писатели, художники-графики, издательское дело, маркетологи, редакторы и т. д.), и постепенно разрабатывают книгу глава за главой в соответствии со схемой Scrum» ( Scrum for Non-Software Projects , 2010). .
Использование Scrum в компании венчурного капитала
Джефф Сазерленд — старший советник Openview Venture Partners, компании венчурного капитала, базирующейся в Бостоне, Массачусетс. В 2010 году он написал статью для Гавайской международной конференции по системным наукам под названием « Организационная трансформация с помощью Scrum: как группа венчурного капитала делает вдвое больше, выполняя половину работы », в которой описывается, как Openview использует Scrum в управлении своим портфелем.
Команды Openview используют Scrum в проектах «в управлении, продажах, маркетинге, финансах и поддержке клиентов портфельных компаний», а также внедряют Scrum в свои портфельные компании (Sutherland, 2010, стр. 1). В одном из примеров использования Scrum команда Labs использует однонедельные спринты для выполнения операционных проектов с добавленной стоимостью для своих портфельных компаний, проведения должной осмотрительности и институционализации своих возможностей по добавленной стоимости.
Когда команда Лаборатории впервые внедрила Scrum, повышенная прозрачность текущих проектов заставила их осознать, что некоторые проекты на самом деле были малоценными.В результате они сократили 30 процентов своих проектов, что освободило место для более ценных проектов и позволило им сосредоточиться на них и завершить их. На самом деле, эта ясность фокуса и ограничение объема незавершенной работы в спринте помогли команде стать более продуктивной, поскольку проекты больше не затягивались на длительные периоды времени, потому что слишком много выполнялось одновременно. Команда уже удвоила свою производительность и находится «на пути ко второму удвоению производительности», продолжая адаптироваться (Сазерленд, 2010, с.8).
Схватка в церкви
Преподобная Арлин Сазерленд работает временным пастором унитарной универсалистской церкви. Она также является женой Джеффа Сазерленда, одного из соавторов Scrum. В статье 2009 года для конференции Agile2009 под названием Scrum in Church: Saving the World One Team at a Time преподобная Сазерленд описала свой опыт использования Scrum в церквях Массачусетса, Коннектикута, Флориды, Делавэра и Вирджинии.
Scrum в основном используется офисным персоналом и волонтерами как для «поддержки работы двигателя», так и для «новых инициатив» (Sutherland, 2009, p.3). Проекты в различных областях программирования, таких как пастырская забота, дети и молодежь, развитие членства, социальная справедливость, музыка, помещения, финансы и сбор средств, управлялись с помощью Scrum.
В каждом экземпляре было сделано несколько изменений для удовлетворения потребностей членов команды и ограничений их среды. Например, было невозможно проводить ежедневные очные стендапы, когда более половины команды выполняли дневную работу. Таким образом, Skype использовался, поскольку «наибольшая демографическая группа, использующая Skype, — это бабушки и дедушки, (и) даже более старые, менее технологически продвинутые участники часто являются опытными пользователями» (Sutherland, 2009, p.4).
Стоит отметить, что Сазерленд обнаружил, что «каждый раз, когда Scrum внедряется в систему, ее необходимо адаптировать» (Sutherland, 2009, стр. 4). Первоначально обескураженная тем, что ее реализации Scrum никогда не соответствовали идеалу «настоящего Scrum», она быстро поняла, что преимущества подлинного адаптивного изменения включают адаптацию самого Scrum.
Что случилось с…?
Поскольку это лишь краткий обзор Scrum, ожидается, что у читателя может остаться несколько вопросов без ответа.В этом разделе мы рассмотрим три основных вопроса, которые чаще всего задают новички в Agile и Scrum, а затем дадим вам несколько заключительных слов о том, где найти дополнительную информацию.
Что случилось с диаграммами Ганта и другой документацией?
Диаграммы Ганта обычно не используются в проектах Scrum. Диаграммы Burndown (как спринтов, так и релизов), доски задач, невыполненные работы, планы спринтов, планы релизов и другие диаграммы показателей используются вместо этого для сообщения о ходе выполнения, состоянии и прогнозах.Существует множество инструментов гибкого управления проектами для предоставления такого типа отчетов панели мониторинга, включая подключаемые модули для Microsoft Project.
Единственными артефактами, требуемыми Scrum, являются невыполненная работа по продукту, невыполненная работа по спринту, выработка релиза и выработка спринта. Все другие формы документации оставлены на усмотрение команды. Эмпирическое правило Agile заключается в том, что если артефакт добавляет ценность и клиент готов за него платить, то артефакт должен быть создан. Артефакты, созданные потому, что «это в контрольном списке» или «мы всегда так делали», — это элементы, которые следует рассмотреть для устранения.Документы, необходимые для вопросов управления (аудит, бухгалтерский учет и т. д.), по-прежнему необходимо создавать, но часто их можно упростить.
Что случилось с менеджером проекта?
Менеджер проекта часто становится скрам-мастером. Это не всегда так, и существует множество различных перестановок преобразования. Например, руководитель проекта, выступавший в качестве эксперта в предметной области или предметной области, мог бы занять более выгодное положение в качестве владельца продукта. Или менеджер проекта, возглавляющий команду из 50+ человек, может остаться в этой роли и сосредоточиться на общих задачах проекта, таких как закупки и переговоры по контракту, в то время как команды Scrum работают над проектом (помните, команда Scrum состоит из 7 +/- 2 человек). , поэтому проект из 50 человек будет состоять из 6-10 Scrum-команд), у каждой из которых есть свой Scrum-мастер.В этом сценарии менеджер проекта помогает скрам-мастерам в координации, разработке стратегии и устранении препятствий.
Что случилось с использованием подробных задач и оценок задач для создания прогнозов?
Традиционная оценка и планирование используют восходящий метод, при котором все требования должны быть полностью определены, а затем создаются и оцениваются задачи на основе этой фиксированной области. Agile-оценка и планирование вместо этого используют для прогнозирования нисходящий метод. Оценка общего уровня на уровне функций часто выполняется с использованием метода, называемого покером планирования, при этом оценки даются в пунктах с использованием последовательности Фибоначчи.Команды определяют свою скорость в очках, то есть сколько очков в среднем команда может набрать за спринт. Стоимость одного очка определяется путем подсчета заработной платы команды за период x, а затем деления ее на количество очков, набранных за период x. Когда у вас есть средняя скорость вашей команды и общее количество невыполненных работ по продукту, вы можете спрогнозировать этапы проекта и даты завершения, а также стоимость за единицу и, таким образом, спрогнозировать стоимость проекта.
Одного абзаца недостаточно, чтобы осветить эту тему, так как на эту тему написаны целые книги.Отличная книга с практическими советами о том, как проводить оценку с использованием покера планирования и прогнозирования с использованием скорости и баллов, — « Agile Estimating and Planning » Майка Кона.
Final Words
Scrum — это гибкая структура управления проектами, которая помогает командам создавать ценные продукты итеративно и поэтапно, постоянно проверяя и адаптируя процесс. Члены Института управления проектами обнаружат, что они могут внедрить Scrum и при этом соблюдать Руководство A Guide to the Project Management Body of Knowledge (PMBOK ® Guide) — четвертое издание, поскольку оба пропагандируют принцип «планируй-делай-проверяй-действуй». подход к управлению проектами.
Это был краткий обзор Scrum, и поэтому он не касался многих дополнительных областей интереса, таких как дорожные карты продукта, оценка с использованием баллов, пользовательские истории, карты историй и так далее.