Agile управление: Доклад «Agile-подход в государственном управлении»

Что такое гибкое управление проектами?

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

Понимание гибкого управления проектами

Ранее, когда проект начинается, разработчик занимается разработкой программного обеспечения с использованием кода, отлаживает его всякий раз, когда он ошибается, исправляет его и все, что сделано. Разработанный код эффективно подходит для клиента или нет, вопрос. Создание небольшого фрагмента проекта казалось немного сложным. Как и когда сложность проекта увеличивается, так и трудности в процессе разработки программного обеспечения. Именно тогда появились модели разработки программного обеспечения. Для каждого цикла разработки было обучение из предыдущих итераций. Так возник термин Agile с 2001 года.

Важные аспекты гибкого управления проектами

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

1. Командное взаимодействие. В процессе разработки программного обеспечения, а не только в процессе рассказа и процессов, существует необходимость в групповом взаимодействии. Именно тогда проект может привести к успеху очень эффективным способом.
2. Упрощенный подход: гибкая методология основана на работе с блоками, называемыми «спринтами». Это приводит к упрощенному подходу к дальнейшему развитию.
3. Сотрудничество с клиентами. Участие клиента в проекте играет очень важную роль в управлении Agile, поэтому проект ориентирован на клиента.
4. Реагируйте на немедленные изменения: если есть какие-либо изменения, сделанные на любом из этапов разработки. Немедленные изменения могут быть реализованы в Agile.

12 принципов гибкого манифеста

12 принципов Agile Manifesto заключаются в следующем:

1. Первый принцип — подход, ориентированный на клиента, и его обновление.
2. Вносить изменения всякий раз, когда и где требуется, даже в конце стадии разработки для любых конкурентных изменений.
3. Своевременная доставка программного обеспечения клиентам с большей гибкостью.
4. Сотрудничество между бизнесом и командами разработчиков.
5. Поддерживать и мотивировать члена команды, проявляющего интерес к проекту. Дайте им ту дополнительную работу, которую они хотели бы сделать, и доверьте им выполнение этой работы.
6. Имейте личную интеграцию с командой.
7. Рабочее программное обеспечение является основной мерой прогресса.
8. Гибкие процессы способствуют устойчивому развитию для всех.
9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
10. Простота гибкой среды.
11. Лучшие практики поступают от самоорганизующихся команд.
12. Эффективно работать внутри и кросс-функциональных команд.

Agile Practices

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

1. Гибкое планирование

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

Это планирование выполняется на 3 уровнях:

а. План релиза: владелец продукта участвует в этом этапе, когда должен происходить релиз проекта на каждом этапе.

б. План итерации: на каждой итерации члены команды планируют и работают вместе.

с. Ежедневный план: Каждый день проводится обсуждение проекта и встреча планов для отслеживания хода выполнения проекта.

2. Тестирование в Agile

На каждом этапе разработки проекта проводится тестирование. Гибкая команда разработчиков также участвует в тестировании. Что происходит двумя способами:

а) Ручное тестирование

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

б) Автоматизированное тестирование

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

3. Что нужно помнить в Agile

а) Неправильное планирование

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

б) гибкие знания

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

Рекомендуемые статьи

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

1. Гибкая модель для разработчиков и тестеров
2. Область управленческого учета
3. Agile Design и его важность
4. Введение в основы 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.Концепция легко гуглится, но основная мысль понятна из графикеской схемы:

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

Вот какие задачи я поставил себе на самом первом этапе:

1. Определение всех требований к проекту

2. Определение текущего результата

3. Постановка конкретных задач команде

4. Оценка задач и формирование плана

5. Выбор процесса разработки

Вот что конкретно было предпринято на первом этапе:

1. Мы начали использовать Jira. Пришлось обучать команду, так как никто не работал ранее с этой системой

2. Мы создали Kanban доску со стандартными этапами, как To Do, In Progress, Test, Done

3. Я описал все требования команде и совместно с командой мы поставили первые задачи, сформировали бэклог продукта. Пришлось все уточнять у команды, так как было совершенно не понятно что уже реализовано и как конкретно реализуется то или иное требование инструментами DS и CV

4. Оценили с командой задачи в днях и согласовали со стейкхолдерами дедлайны

5. Сделали совместные чаты и т. д., чтобы коммуникация наконец-то было централизована.

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

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

С какими основными проблемами мы столкнулись:

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

• Команда очень слабо работала с Jira. Всегда приходилось двигать таски и актуализировать доску насильственно…

• Цикл выполнения задачи был очень большой из-за очень общей задачи и мог занимать до 3 месяцев

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

• Деплой проекта на объекты был крайне хаотичен, делался по требованию и постоянно возникали проблемы

Мы проанализировали эти проблемы и решили попробовать Scrum (как ни странно, тогда это звучало логично)

Этап 2.

Перед тем, как начать разработку по Scrum, я внимательно пересобрал общий бэклог проекта, описал его в формате обычных Tasks и User story, приоритизировал его. 

На самом старте в нашей Scrum доске были все те же колонки To Do, In Progress, Test, Done

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

1. Обсудили процесс CI/CD и решили добавить UAT окружение.

2. Добавили соответствующий статус на доске — UAT

3. Оценили задачи в story points

4. Поставили задач на спринт

5. Проговорили правила работы и ответственность

После завершения нескольких спринтов оказалось, что мы каждый спринт закрываем совершенно разное количество 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. Выбрали первые задачи и начали работу

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

1. Мы могли брать супер срочные задачи и выполнять сразу же

2. Мы сразу смогли увидеть на каком этапе у нас застревают задачи

3. Мы стали понимать как лучше распределить ресурсы

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

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

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

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

Таким образом мы пришли к идеальному формату работу для нашей команды. 

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

P.S. очень рекомендую прочитать книгу LeanDS менеджерам или Data Science инженерам, так как это сильно прокачает как минимум какие-то аспекты ваших процессов.

Совмещение традиционного и гибкого типов управления проектом

Гибкое управление проектами — руководство для начинающих

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

Но когда вы начнете исследовать, какая методология подходит именно вам, вы, вероятно, снова и снова увидите одно конкретное слово:

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 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:

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

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

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

4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.

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

6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.

7. Работающее программное обеспечение является основным мерилом прогресса.

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

9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.

10. Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.

11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.

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

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

Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.

Каковы преимущества гибкого управления проектами?

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

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

Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.

Большая адаптивность (и меньший риск)

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

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

Повышение удовлетворенности клиентов

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

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

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

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

Более счастливые команды

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

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

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

Как стать гибким

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

Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.

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

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

Привлеките к работе нужных людей

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

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

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

И привлечь к работе нужных людей

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

1. Организационная культура, противоречащая ценностям Agile

2. Общее сопротивление организации изменениям

3. Неадекватная поддержка и спонсорство со стороны руководства от всех — включая руководство. Респонденты опроса высоко оценили внутренних 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 для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.

   Вот примерное представление о том, как это работает:

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

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

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

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

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

   6. Повторять, повторять, повторять.

   Какая гибкая методология мне подходит?

   Если вы все еще пытаетесь решить, какую методологию выбрать — 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 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:

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

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

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

   4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.

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

   6. Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.

   7. Работающее программное обеспечение является основным мерилом прогресса.

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

   9. Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.

   10. Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.

   11. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.

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

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

   Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.

   Каковы преимущества гибкого управления проектами?

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

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

   Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.

   Большая адаптивность (и меньший риск)

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

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

   Повышение удовлетворенности клиентов

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

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

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

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

   Более счастливые команды

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

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

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

   Как стать гибким

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

   Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.

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

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

   Привлеките к работе нужных людей

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

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

   Как Teamwork использует Teamwork: набор и адаптация

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

   И привлечь к работе нужных людей

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

   1. Организационная культура, противоречащая ценностям Agile

   2. Общее сопротивление организации изменениям

   3. Неадекватная поддержка и спонсорство со стороны руководства от всех — включая руководство. Респонденты опроса высоко оценили внутренних 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 для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.

      Вот примерное представление о том, как это работает:

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

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

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

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

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

      6. Повторять, повторять, повторять.

      Какая гибкая методология мне подходит?

      Если вы все еще пытаетесь решить, какую методологию выбрать — 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 ?
      1. Индивидуумы и взаимодействия важнее процессов и инструментов.
      2. Рабочее программное обеспечение по исчерпывающей документации.
      3. Сотрудничество с клиентами в ходе переговоров по контракту.
      4. Реакция на переход по плану.

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

      Каковы 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
      1. Удовлетворение потребностей клиентов за счет ранней и непрерывной разработки программного обеспечения.
      2. Примите меняющиеся требования в процессе разработки программного обеспечения.
      3. Концентрация на частой поставке рабочего программного обеспечения.
      4. Заинтересованные стороны бизнеса и разработчики программного обеспечения сотрудничают на протяжении всего процесса разработки.
      5. Обеспечьте надлежащую среду и поддержку команде разработчиков, чтобы они могли чувствовать себя мотивированными. Доверие также необходимо.
      6. Общение лицом к лицу упрощает обмен информацией между владельцами проекта и командами.
      7. Функциональное программное обеспечение является истинным мерилом прогресса.
      8. Процесс разработки Agile поддерживает устойчивое развитие. Заинтересованные стороны бизнеса, разработчики и клиенты должны иметь возможность поддерживать постоянный и неопределенный темп.
      9. Постоянное внимание к хорошему дизайну и техническому совершенству повышает маневренность.
      10. Простота необходима, поскольку она предполагает максимальное увеличение незавершенной работы.
      11. Самоорганизованные команды часто создают лучшие решения.
      12. Часто команда размышляет о том, как стать более эффективной, и соответствующим образом корректирует свое поведение.
      Термины и определения 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-команде понять весь потенциал и назначение кода, а также то, как он должен работать, еще до того, как он будет разработан.

      Способы использования методологии Agile

      Agile направлен на создание более коротких циклов разработки и частых выпусков продуктов, в отличие от традиционного каскадного управления проектами. Из-за более коротких временных рамок команды могут более эффективно реагировать на изменения в потребностях клиентов. Тем не менее, методология 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
      • Расширенные варианты безопасности
      • Управление ошибками
      • Опции поиска и фильтрации
      • Инструменты для создания дорог
      Pricing :

      Платные планы начинаются с 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 включают:

        1. Индивиды и взаимодействие через процессы и инструменты
        2. Рабочее программное обеспечение поверх исчерпывающей документации
        3. Сотрудничество с клиентами по поводу переговоров по контракту
        4. Реагирование на переход по плану

        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, и поэтому он не касался многих дополнительных областей интереса, таких как дорожные карты продукта, оценка с использованием баллов, пользовательские истории, карты историй и так далее.

        No related posts.