Agile управление: Знакомство с agile-управлением проектами | Atlassian — Независимое театральное объединение "Зрительские симпатии"

Содержание

Знакомство с agile-управлением проектами | Atlassian

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

Просмотр тем

Что такое управление проектами по методике agile?

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

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

Вот что вам нужно знать, чтобы начать работу с agile или использовать эту методику эффективнее.

ЧИТАЙТЕ НИЖЕ

Статьи об agile-управлении проектами

[ПРОДОЛЖЕНИЕ]

История

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

Традиционный agile-подход к управлению проектами включает две методологии: Scrum и Kanban. Scrum предполагает итерации с фиксированной продолжительностью, а Kanban — непрерывные релизы. По окончании одного команда сразу переходит к следующему.

Принципы работы Scrum

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

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

Четыре составляющих Scrum

Планирование спринтов	ДЕМОНСТРАЦИЯ СПРИНТА	Ежедневные стэндапы	Ретроспектива
Собрание команды по планированию для определения объема работы на следующий спринт.	Общее собрание с демонстрацией результатов, достигнутых командой в ходе работы над последним спринтом.	Известно также как «стендап»: короткое 15-минутное совещание для синхронизации работы команды.	Обзор удачных и неудачных событий текущего спринта и обсуждение действий для улучшения следующего спринта.

Scrum-доска

Scrum-доска используется для визуализации работы в рамках спринта. В ходе собрания по планированию спринта команда перемещает элементы из бэклога продукта в бэклог спринта. На scrum-досках рабочие процессы представляются по этапам, например Сделать, В работе и Готово. Scrum-доски — это основной компонент для повышения прозрачности при agile-управлении проектами.

Принципы работы Kanban

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

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

Четыре компонента Kanban

Список работы (истории)	Столбцы или полосы	Лимиты задач в работе (WIP)	Непрерывные релизы
Список работы (истории) — это проблемы или задачи, которые необходимо решить.	Используются в kanban-досках для разделения задач, соответствующих различным рабочим процессам, пользователям, проектам и т. д.	Правило для ограничения объема работы на основании ресурсов команды.	Команда работает над определенным числом историй в пределах лимита WIP и может выпустить релиз в любое время.

Kanban-доска

Kanban-доска используется для визуализации выполняемой работы. Она также полезна при планировании ресурсов, поскольку руководители проектов видят задачи и могут определить соответствующие сроки. Kanban-доска состоит из столбцов и полос, по которым истории движутся по мере выполнения. Истории остаются в столбце «Сделать» до тех пор, пока лимит WIP не позволит перейти к следующей задаче. Перечень работ необходимо разделять на относительно небольшие задачи и располагать в порядке приоритета. Как видно из этого примера, с помощью полос можно отделять более приоритетные задачи от «всего остального».

Оцените, запишите и распланируйте

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

Оценка проекта по методике agile

Оценка проекта — это необычайно важный аспект управления проектами и в Kanban, и в Scrum. Kanban-команды в большинстве своем устанавливают лимиты WIP для каждого этапа работы, исходя из своего опыта и размера команды. Scrum-команды определяют, сколько работы можно сделать в рамках одного спринта, путем оценки проекта. Многие agile-команды для вычисления этого значения используют уникальные методики, такие как покер планирования, оценка в идеальных часах или в очках за истории. Это дает точку отсчета, благодаря которой в процессе ретроспективы спринта становится понятно, как идет работа. Jira Software можно настроить с учетом уникальной системы оценки проекта, используемой той или иной командой.

Agile-отчеты

Оценку проекта следует выполнять в начале и в конце каждого спринта. Таким образом, в начале спринта команда определяет, что можно сделать, а в конце — насколько точной была первоначальная оценка. Agile-отчеты, например диаграммы сгорания, показывают, сколько «очков за историю» будет отработано в течение спринта. Jira Software предлагает десятки встроенных отчетов, в которых эффективность команды отображается в режиме реального времени. Данные, на которые можно опираться в ретроспективах, открывают перед вами невероятные возможности по улучшению своей работы.

Бэклог: ведение и управление

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

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

Claire Drumond

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

Топ-7 методов управления проектами: Scrum, Kanban, PRINCE2..

08 Июл 2016

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

У человечества за всю историю накопился внушительный список успешно реализованных сложных проектов. От строительства Пирамид в Гизе до отправки человека на Луну, самые смелые человеческие начинания требовали слаженной работы тысяч людей. А это подразумевает сложную систему управления проектами.

И хотя лишь единицы из нас столкнутся с задачами такого масштаба, большинство читателей этого блога так или иначе сталкивается с проектным управлением. По оценкам PMI к 2020 году появятся 15 миллионов новых позиций проектных специалистов – а многим другим профессионалам зачастую приходится руководить мини-проектами, хотя бы на личном уровне.

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

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

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

В этой статье мы рассмотрим:

Классический проектный менеджмент
Agile
Scrum
Lean
Kanban
Six Sigma
PRINCE2

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?», а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC), тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1.

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2.

Изобретённая независимо Королем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

Классическое проектное управление

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3.

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

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

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

Как уже говорилось ранее – не все проекты могут быть структурированы таким образом, чтобы быть реализованными по классическому проектному подходу. Возвращаясь к нашему примеру с шеф-поваром: приготовление одного блюда идеально ложится на «водопадный» подход, а вот вовремя приготовить и подать ужин из четырёх блюд будет практически невозможно, если придётся каждый раз ждать окончания приготовления одного блюда, чтобы приступить к приготовлению другого.

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5.

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть здесь – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto), закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

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

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

Вотчина Agile – разработка новых, инновационных продуктов. В проектах по разработке таких продуктов высока доля неопределённости, а информация о продукте раскрывается по ходу проекта. В таких условиях реализовывать проект по «водопаду» становится невозможно– нет информации для планирования.

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Встреча по упорядочиванию беклога (Backlog Refinement Meeting, «Backlog Grooming»): Эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него него зависит, какую ценность получит Заказчик по итогам спринта.
Планирование Спринта: После того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике Scrum. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.
Ежедневные летучки: Каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, Scrum Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.
Подведение итогов Спринта: Цель этапа – обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.
Ретроспектива Спринта: Проводится сразу после Подведения итогов спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

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

Сильные стороны Scrum

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

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

В ходе каждой итерации, разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество Scrum в том, что он позволяет «быстро ошибаться». Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.

Слабые стороны Scrum

Scrum очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую команду очень непросто!

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

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

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

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

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

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

6 сигм очень похожа на Kanban, только с установленными этапами реализации задач – планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении 6 сигм будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. И, как и Kanban, 6 сигм можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации – без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта.

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

Кроме того, основной лейтмотив 6 сигм: «Всё всегда можно сделать ещё лучше». Это может демотивировать сотрудников, не чувствующих удовлетворения от проделанной работы. Кроме того, если проект единичный и компания не планирует в будущем реализовывать подобные проекты, все затраты на анализ и извлечение уроков могут оказаться напрасными.

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

Специализированных аспектов управления проектом, например, отраслевых;
Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т. п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
7 процессов определяют шаги продвижения по проектному циклу;
7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

Кроме того, PRINCE2 рекомендует адаптировать методологию под каждую конкретную организацию.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

Бизнес-аспект (Принесёт ли этот проект выгоду?)
Потребительский аспект (Какой нужен продукт, что мы будем делать?)
Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Starting up a project):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
Инициация проекта (Initiation a project):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
Руководство проектом (Directing a project): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
Контроль стадии (Controlling a stage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
Управление созданием продукта (Managing Product Delivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
Управление границами стадии (Managing a stage boundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
Завершение проекта (Closing a project):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

Адаптируемость к особенностям организации;
Наличие чёткого описания ролей и распределения ответственности;
Акцент на продуктах проекта;
Определённые уровни управления;
Фокус на экономической целесообразности;
Последовательность проектной работы;
Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

Отсутствие отраслевых практик;
Отсутствие конкретных инструментов для работы в проекте.

Лучшая система управления проектами … для Вас!

Управление проектами – это наука, но наука не самая точная. В данной области нет незыблемых основ и универсальных решений. Если вам удастся найти метод, идеально подходящий вашему проекту – считайте, что вам крупно повезло, ведь большинству менее удачливых руководителей приходится прикладывать усилия для создания и настройки собственных систем управления проектами. Эти системы могут быть составлены из элементов существующих систем или даже созданы совершенно с нуля, как в случае с миссией «Аполлон». Главное используйте что-нибудь, что даст вам хоть какую-то структуру и позволит не забыть о том, что главное для вашего проекта.

Как получить международный сертификат по Agile?

Для тех, кто хочет получить систематизированное понимание Agile, разобраться с преимуществами и недостатками гибкого подхода к проектам и продуктам, найти области наилучшего применения Agile и получить международный сертификат ICAgile Certified Professional — наш тренинг «Agile Certified Professional»

Наши курсы и тренинги:

Курс «Управление проектами на базе PRINCE2»
Тренинг «Agile Certified Professional»
Базовый курс управления проектами

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

Статья: Партизанский Аджайл
Статья: ТОП-4 Методологии управления проектами
Статья: Разница между Scrum и Kanban

Подписывайтесь на наши соцсети, чтобы не пропускать новые статьи:

Telegram-канал «Проектных сервисов»
Telegram-канал Андрея Бадина, CEO «Проектных сервисов», — «Управляй иначе»
YouTube
VK

Источник: https://zapier. com/learn/ultimate-guide-to-project-management/project-management-systems/

AgilePRINCE2ScrumМетодологияМетодология управления проектамиПроектное управлениеСтандарты

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

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

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

Метод Agile: определение и краткая история

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

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

Идеи Agile:

Люди и их взаимодействие важнее, чем процессы и инструменты
Рабочее ПО важнее, чем документация
Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

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

Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
Позволять членам команды самостоятельно принимать решения (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)

Постоянно адаптироваться к меняющейся среде (благодаря этому конечный продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

Члены команды и клиент в большинстве случаев работают вместе и рядом.

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

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

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

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

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

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

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

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Ключевые слова:1Упрврем

Легендарный agile: в чём его суть и чем он полезен в управлении проектами

Любой проект — от разработки приложения для iOS до вывода на калужский рынок новой ватрушки — превращается в ад, если им неправильно управлять. Бесконечные корректировки, согласования, переделки, новые идеи на середине проекта… Раньше всех эта ситуация надоела IT-сектору, где стали применять гибкие методы управления проектами, или подход Agile.

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

Agile — что это такое
Преимущества и недостатки Agile
- Преимущества
- Недостатки
Ценности Agile
- Люди и их взаимодействие важнее процессов и инструментов
- Работающий продукт важнее документации
- Сотрудничество с заказчиком важнее соблюдения формальных условий
- Готовность к изменениям важнее, чем следование плану
12 принципов Agile
- Наивысший приоритет — удовлетворение заказчика
- Изменения приветствуются
- Работающий продукт следует выпускать как можно чаще
- Поддержка контакта между командой и заказчиком
- Мотивация сотрудников
- Простота общения с командой и внутри неё
- Самоорганизация и самоконтроль команды
- Постоянный темп работы
- Максимальное упрощение решений, процессов и документации
- Непрерывное улучшение
- Постоянный анализ и поиск возможностей оптимизации
- Работающий продукт — главный показатель прогресса
Методы Scrum и Kanban в Agile
- Scrum
- Kanban
Какие компании используют гибкую методологию
- Мир
- Россия
Книги об Agile
Заключение

Agile — что это такое

Понятие agile, или эджайл, происходит от англ. agile — «проворный». Это довольно удачная формулировка, ведь agile-команды более проворные: они стараются как можно раньше начать работу с минимальным требованиями и сроками, пока другие долго планируют, прикидывая сроки и бюджеты.

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

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

планирование,
проектирование,
разработку,
внедрение,
оценку.

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

Этапы работы с проектом по Agile

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

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

Преимущества и недостатки Agile

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

Преимущества

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

Удаётся раньше вывести продукт на рынок и вносить изменения прямо в ходе разработки, а не переделывать по завершении.

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

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

Разница Waterfall и Agile

Недостатки

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

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

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

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

Ценности Agile

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

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

В Agile нет места закостенелым «так надо» и «так принято». Инструменты и процессы служат команде, а не наоборот.

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

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

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

Задача agile-команды — сделать готовый продукт, который понравится клиенту.

Согласно гибким методам, не нужно доводить продукт до идеала, чтобы его выпустить. Продукт выполняет основные функции? Значит, можно выпускать. А доработки — уже в следующих версиях.

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

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

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

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

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

Будущее невозможно предсказать, поэтому нужно быть достаточно гибкими, чтобы под него подстраиваться. Случиться может всё что угодно: дизайнер заболеет, клиент изменит ТЗ, менеджер уволится.

Представим команду, которая делает торты и пирожные. Один из популярных продуктов — шоколадный торт. Но когда шоколад дорожает на 50%, agile-команда вместо повышения цены находит новый рецепт. Оставляет шоколада в составе на 50% меньше, но добавляет новые компоненты: сгущёнку и заварной крем. В итоге цена остаётся прежней, а покупатели даже ничего не замечают.

12 принципов Agile

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

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

Ниже подробнее рассказываем о 12 принципах гибкой разработки ПО.

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

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

Изменения приветствуются

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

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

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

Поддержка контакта между командой и заказчиком

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

Мотивация сотрудников

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

Простота общения с командой и внутри неё

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

Самоорганизация и самоконтроль команды

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

Постоянный темп работы

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

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

Максимальное упрощение решений, процессов и документации

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

Лучше сделать меньше, но сосредоточиться на максимально качественном исполнении, чем распыляться на множество версий и ни одну не довести до ума.

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

Непрерывное улучшение

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

Постоянный анализ и поиск возможностей оптимизации

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

Работающий продукт — главный показатель прогресса

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

Методы Scrum и Kanban в Agile

Есть много подходов к проджект-менеджменту, основанных на Agile. Самые популярные из них — это Scrum и Kanban.

Scrum

Над проектом работает команда специалистов, чаще всего в ней есть product owner (владелец продукта) и scrum-master (модератор). Разработка делится на спринты: строго фиксированные периоды от 1 до 4 недель. Каждый спринт начинается с определения задач, а заканчивается подведением итогов. Участники команды каждый день встречаются и обсуждают промежуточные итоги.

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

Kanban

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

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

Какие компании используют гибкую методологию

Мир

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

Сейчас Agile используют в работе крупные международные компании, такие как Google, Microsoft, Adobe, Netflix, Spotify, Oreo, Saab и многие другие.

Россия

В России Agile появился позже, но быстро прижился в IT-компаниях, а затем перекочевал в другие сферы. Им пользуются Сбербанк, М.Видео, ivi, 12Storeez и «АльфаСтрахование».

Книги об Agile

«Scrum. Революционный метод управления проектами». Автор: Джефф Сазерленд. Книга от автора Scrum подойдёт для знакомства с методикой и расскажет, как повысить эффективность выполнения проектов.
«Постигая Agile». Авторы: Эндрю Стеллман и Дженнифер Грин. Руководство по основным agile-методологиям: Scrum, Kanban, Lean и XP (eXtremal Programming).
«Эпоха Agile. Как умные компании меняются и достигают результатов». Автор: Стивен Деннинг. Рассказывает, как команды в крупных компаниях внедряют Agile на разных уровнях.
«Канбан и “точно вовремя” на Toyota. Менеджмент начинается на рабочем месте». Сборник статей о внедрении Kanban на заводе Toyota в 1970-е годы. Базовая книга о методе kanban.
«Путь скрам-мастера». Автор Зузана Шохова. Практическое руководство по системе scrum от опытного скрам-мастера. Рассказывает о том, как создать эффективную и производительную команду.
«Agile: оценка и планирование проектов». Автор: Майк Кон. О том, как оценивать, планировать и управлять agile-проектами. В книге много практики, рекомендаций, графиков и методов.

Заключение

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

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

Agile методология — принципы Agile управления проектами

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

Agile зародился в IT-индустрии на фоне проблем в разработке продуктов.

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

Активные попытки создать новые методы и подходы к проектам по программированию начались в 90-х годах. В это время появились такие методы, как RAD, XP, Scrum и т.д.

В 2001 году в США группа независимых практиков сформулировала новый подход, включающий в себя самые успешные принципы разработки продуктов. Этот метод был альтернативой сложным и тяжеловесным моделям управления проектами, например, водопадной. Новый подход заключался в гибкой системе управления и был назван словом «Agile».

Что такое Agile

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

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

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

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

В чем секрет популярности аджайла, узнаете в статье «Agile – новый Lean?» на нашем портале.

Манифест

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

Манифест не дает четких инструкций, определений или требований к процессу управления проектами, не сообщает, что правильно или неправильно.

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

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

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

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

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

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

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

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

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

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

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

12 принципов Agile

Кроме четырех ценностей, Agile также описывает 12 принципов. Чтобы внедрить аджайл-культуру в работу компании или отдельных проектов, нужно встроить эти принципы в работу проектной команды.

Наивысший приоритет – непрерывный прогресс. Для этого команда должна регулярно поставлять работающий продукт заказчику.
Принятие изменений в требованиях даже на поздних этапах разработки продукта. Аджайл позволяет внедрять изменения для улучшения продукта и его конкурентоспособности.
Стремление поставлять работающий продукт каждые несколько недель, в крайнем случае – раз в несколько месяцев. Чем выше частота поставок, тем лучше.
Самый результативный способ передачи информации – встретиться лично.
Представители бизнеса и разработчики продукта должны работать совместно.
В процессе должны участвовать только мотивированные люди. Нужно создать для них комфортную рабочую среду, дать необходимые инструменты и доверить им делать свою работу.
Главный показатель успешности проекта – работающий продукт.
Гибкие процессы помогают постоянному развитию. Заказчик, разработчики и пользователи должны поддерживать постоянный темп работы в течение всего рабочего процесса.
Внимание к техническому совершенству и качественному построению работы делает процесс разработки более гибким.
Простота помогает избежать лишней работы.
Лучшая архитектура, требования и дизайн создаются в самоорганизующихся командах.
Команда должна непрерывно искать пути для повышения эффективности с помощью настройки и изменения своих действий.

Главные отличия от Scrum и Kanban

Главное отличие Agile от Scrum и Kanban в том, что Agile – это философия, а Scrum и Kanban – фреймворк и метод работы, которые соответствуют ценностям аджайл.

Scrum – это самый популярный фреймворк. В Scrum работа измеряется короткими по продолжительности отрезками времени – спринтами. Работа выполняется небольшой командой, до 10 человек. Обычно в команду входят: заказчик продукта, разработчики, если это ИТ-проект, и скрам-мастер.

Kanban для отслеживания задач тоже использует визуальную доску. Чем дальше вправо идет задача, тем она ценнее, тем больше на нее потратили времени и денег. Поэтому такую задачу лучше быстрее закрыть, она приоритетнее, так как быстрее принесет пользу. Чем быстрее задачи проходят до конца доски, тем эффективнее работа команды. Процессы канбана строятся не по спринтам, а по этапам выполнения задач: «сделать», «в процессе», «тестирование», «согласование» и так далее в зависимости от того, какие статусы решит ввести сама команда.

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

Плюсы и минусы

Если аджайл подходит для вашего конкретного проекта, тогда проявляются плюсы:

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

Минусы Agile-подхода:

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

Как внедрить Agile в работу компании

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

Сначала надо определиться с целями. Их нужно ставить по Smart-методу постановки целей, основанному на пяти принципах: конкретности, измеримости, достижимости, важности и определенности. Важно понять, зачем вы хотите внедрить Agile, на какие метрики в работе компании желаете повлиять.
Проанализировать все проекты и понять, какие из них могут быть модернизированы с помощью гибкого подхода и сколько их. Если таких проектов нет, то вопрос о внедрении можно снять.
Понять, сможете ли вы реализовать эти цели. В этом поможет тестовый запуск аджайл-модели для одного из проектов. Для этого надо выбрать один из фреймворков, например, Scrum – он сейчас наиболее популярен. Выберите пилотный проект, на нем проведите обучение сотрудников и протестируйте работу. Желательно для этого пригласить профессионального Scrum-мастера или аджайл-коуча, чтобы он помог первой команде сделать внедрение.
Затем нужно расселять тех людей, которые научились работать по этому фреймворку, по нескольким командам и постепенно культивировать новую модель взаимодействия. Люди должны научиться работать в новых ролях, по-новому подходить к требованиям к продукту, проводить довольно много совещаний и т.д.

Также есть инструменты, которые помогают на старте понять, подойдет проекту больше аджайл или, например, водопадная модель , а может, гибрид . Один из таких инструментов – это Agile Suitability Model, которая описана Американским институтом управления проектами.

Книги про Agile

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

Книга основателя методологии scrum Джеффа Сазерленда «Scrum. Революционный метод управления проектами» поможет понять, как она работает, какие плюсы и минусы у нее есть, а также даст описание конкретных шагов для внедрения Scrum в работу. Эта книга подойдет для менеджеров, руководителей, разработчиков, а также всех, кто изучает теорию эффективного управления проектами.

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

Что такое Agile-управление и как применять гибкий подход в бизнесе

В 2021 году Agile-подход будет праздновать 20-летие. Но в российских компаниях только зарождается культура гибкого управления. Что такое Agile-управление и нужно ли его использовать в вашем бизнесе?

Что такое Agile-управление

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

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

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

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

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

Каким компаниям необходим agile-подход

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

Основные идеи Agile

Все принципы Agile были сформулированы в Манифесте в 2001 году. Всего четыре идеи, и все они интуитивно понятны:

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

Но как же применять Agile для управления бизнеса? Необходимо сконцентрироваться на особенностях этого подхода. Разберём каждый из них.

Кросс-функциональность команды

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

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

Отчётность с небольшими интервалами

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

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

Как внедрить Agile

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

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

Как выглядит agile-подход на практике

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

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

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

Ссылка скопирована

Начало работы с гибким управлением проектами

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

Обзор тем

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

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

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

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

ЧИТАЙТЕ НИЖЕ

Статьи по управлению проектами Agile

[ПРОДОЛЖЕНИЕ]

History быстро удовлетворяя постоянно меняющиеся потребности своих клиентов.

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

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

Как работает Scrum

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

Все начинается с невыполненной работы или объема работ, которые необходимо выполнить. В скраме есть два бэклога: один — бэклог продукта (принадлежит владельцу продукта), который представляет собой список приоритетных функций, а другой — бэклог спринта, который заполняется путем выбора задач из верхней части бэклога продукта до тех пор, пока мощность для следующего спринта достигнута. Скрам-команды имеют уникальные роли, зависящие от их участия в процессе. Обычно в команде есть мастер схватки или сторонник метода схватки; владелец продукта, голос продукта; и команда Scrum, которая часто является межфункциональной командой, отвечающей за выполнение s@#$.

Четыре церемония Scrum

Планирование спринта	Sprint Demo	Daily Standup	Ретроспектива
.	Деловое собрание, на котором команда показывает, что они сделали за этот спринт.	Также известная как стендап, 15-минутная мини-встреча для команды разработчиков программного обеспечения для синхронизации.	Обзор того, что получилось, а что нет, с действиями по улучшению следующего спринта.

Скрам-доска

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

Как работает канбан

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

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

Четыре компонента Kanban

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

Канбан-доска

Канбан-доска используется для визуализации всей выполняемой работы. Он также используется для планирования ресурсов, позволяя руководителям проектов видеть работу и соответственно разрабатывать сроки. Канбан-доска состоит из столбцов и дорожек, через которые проходят истории на пути к завершению. Истории находятся в столбце «Задачи» до тех пор, пока лимит WIP не позволит работать над следующей задачей. Список работ должен быть разбит на относительно небольшие вопросы и организован по приоритету. Как вы можете видеть в этом примере, дорожки могут помочь отделить элементы с более высоким приоритетом от «всего остального».

Оценивать, составлять отчеты и планировать

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

Оценка проекта Agile

Оценка проекта является чрезвычайно важным аспектом как канбан, так и скрам-менеджмента. Для канбана многие команды устанавливают свой лимит незавершенного производства для каждого штата на основе своего предыдущего опыта и размера команды. Скрам-команды используют оценку проекта, чтобы определить, какой объем работы можно выполнить за конкретный спринт. Многие agile-команды используют уникальные методы оценки, такие как покер планирования, идеальные часы или стори-пойнты, чтобы определить числовое значение для поставленной задачи. Это дает agile-командам точку отсчета, на которую можно ссылаться во время ретроспективы спринта, чтобы увидеть, как их команда выступила. Программное обеспечение Jira можно настроить так, чтобы оно собирало уникальные оценки проектов ваших команд.

Agile-отчетность

Оценки проекта вступают в силу в начале и в конце каждого спринта. Они помогают командам определить, что они могут сделать в начале спринта, а также показывают, насколько точными были эти первоначальные оценки в конце. Agile-отчеты, такие как диаграммы Burndown, показывают, сколько «очков истории» выполнено в течение спринта. Jira Software предлагает десятки готовых отчетов, содержащих полезную информацию об эффективности ваших команд в режиме реального времени. Наличие данных для поддержки ваших ретроспектив — бесценный способ для agile-команд совершенствоваться.

Управление невыполненными работами и подготовка

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

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

Клэр Драмонд

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

Agile или водопадное управление проектами

Редакция: Лаурели Маллек, руководитель программы

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

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

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

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

Что такое каскадное управление проектами?

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

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

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

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

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

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

Преимущества водопада

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

Недостатки водопада

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

Agile против водопада

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

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

Итеративные выпуски открывают для команды многочисленные возможности:

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

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

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

Принципы Agile

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

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

Более высокий потенциал для удовлетворения потребностей клиентов

Время выхода на рынок значительно сокращается

Улучшение видимости и подотчетности

Выделенные команды со временем повышают производительность

Гибкая расстановка приоритетов, ориентированная на получение ценности

Существует организационная кривая затрат на обучение

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

Элементы, которые следует учитывать при переходе на agile

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

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

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

Дорожные карты

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

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

Требования

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

Незавершенная работа

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

Agile-метрики

Agile-команды добиваются успеха благодаря метрикам. Ограничения незавершенного производства (WIP) позволяют команде и бизнесу сосредоточиться на выполнении работы с наивысшим приоритетом. Графики, такие как диаграммы выгорания и контрольные диаграммы, помогают команде предсказать скорость доставки, а диаграммы непрерывного потока помогают выявить узкие места. Эти метрики и артефакты заставляют всех сосредоточиться на больших целях и повышают уверенность в способности команды выполнять будущую работу.

Agile работает на доверии

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

В заключение…

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

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

Дэн Радиган

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

Эпосы, рассказы, темы и инициативы

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

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

Что такое истории, эпосы и инициативы?

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

Agile эпик против истории

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

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

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

Примеры agile-историй:

Пользователям iPhone требуется доступ к вертикальному просмотру прямой трансляции при использовании мобильного приложения.
Пользователям настольных компьютеров нужна кнопка «Просмотр в полноэкранном режиме» в правом нижнем углу видеоплеера.
Пользователи Android должны быть связаны с Apple Store.

Узнайте, как настраивать истории (называемые задачами) в Jira Software

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

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

Полные определения, примеры и рекомендации см. по адресу:

Тренер по Agile: Эпики
Коуч по Agile: Истории

Эпопея Agile против инициативы

3

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

Пример эпиков в инициативе:

Предположим, ваша компания по производству ракет хочет снизить стоимость запуска на 5% в этом году. Это отлично подходит для инициативы, так как ни один эпик вряд ли сможет достичь такой большой цели. В рамках этой инициативы будут такие эпические вещи, как «Снизить расход топлива на этапе запуска на 1%», «Увеличить количество запусков в квартал с 3 до 4» и «Уменьшить все термостаты с 71 до 69 градусов #Dadmode».

В Atlassian:

Внутри компании мы называем наши инициативы «PC Tickets». Заявки Project Central настраиваются в Jira Software так же, как и наши эпики. Каждая команда берет четыре-пять самых важных целей на год и делает для каждой из них билеты на ПК. Эти компьютерные билеты используются основателями и руководством для понимания всей работы, проводимой в компании.

ДАЛЕЕ: Узнайте, как настроить Agile Epics

Инициативы, выходящие за рамки

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

Многие клиенты Atlassian используют расширенные дорожные карты в Jira Software, чтобы представить пять уровней выше agile-эпиков для определения и руководства проектами, которые показаны ниже.

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

Так выглядит планирование с помощью Advanced Roadmaps для подразделения Atlassian Cloud Foundations. Подробнее

Работа по структурированию

Гибкость и всеобъемлющая структура не исключают друг друга, и представленная здесь структура не подходит всем. Успех — это когда вы и ваша команда понимаете эти концепции и адаптируете их к своим потребностям. Для нас это истории, эпики и инициативы.

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

Макс Рекопф

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

Управление программами и управление проектами

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

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

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

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

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

Управление программами и управление проектами

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

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

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

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

Проекты имеют:

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

Программы имеют:

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

Чем занимается руководитель программы?

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

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

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

Оценка состояния портфеля

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

Управление рисками

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

Запуск программы

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

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

Взаимодействие с заинтересованными сторонами

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

Уточнение операционной модели

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

Поддержка решений

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

Фокус и сфера деятельности каждого менеджера программы определяют специфику его взаимодействия с этими практиками.

Чем занимается руководитель проекта?

Обычный день менеджера проекта может включать:

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

Как видите, программа и проект менеджеры работают над тесно связанными задачами. Основное различие между этими двумя ролями заключается в масштабе и неоднозначности:

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

9003999 9003949

Менеджер программы	Менеджер проекта
Стратегии	Планы 9003
Планы
.0045 Provides advice to stakeholders	Tracks progress of projects
Review and advise on projects	Allocates resources
Offers audits and QA	Manage risks
Наставничество для проектных команд	Общение

В заключение…

Институт управления программами отмечает, что «организации со зрелым управлением программами гораздо более успешны, чем без него». Это связано с тем, что управление программами позволяет организациям добиться лучшего соответствия стратегическим целям, управления взаимозависимостью проектов, лучшего управления ресурсами и т. д.

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

Узнайте больше о функциях управления программами Jira Align. Также обязательно ознакомьтесь с расширенными дорожными картами Jira для стратегического планирования.

Лаурели Маллек

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

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

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

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

Agile.

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

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

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

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

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

Простой в использовании, мощный, когда вам это нужно
Teamwork, которому доверяют 20 000 компаний и 6000 агентств, позволяет легко управлять, отслеживать и настраивать несколько сложных проектов. Начните с бесплатной 30-дневной пробной версии.
Попробуйте Teamwork бесплатно
Гибкое управление проектами охватывает множество различных гибких методологий управления проектами, каждая из которых основана на некоторых общих принципах и основных ценностях гибкой разработки.
Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?
Краткая история Agile
Большинство современных гибких методов управления проектами берут свое начало в разработке программного обеспечения. Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.
Они обнаружили, что подводные камни этих тяжеловесных методов, такие как отсутствие гибкости, приспособляемости и даже автономии, затрудняли их реакцию на изменения или применение полученных знаний в ходе работы. Поскольку планы проекта были намечены в самом начале, не было места для неожиданностей, а отклонения могли дорого обойтись.
Но в отличие от отраслей, где процесс был фиксированным, а результат был надежным и стабильным (подумайте: производственный процесс, который создает один и тот же продукт на сборочной линии), изменения являются фундаментальным компонентом программных проектов.
Может быть, требования заинтересованных сторон меняются, или, может быть, тестирование показывает, что что-то работает не так, как должно, когда конечный пользователь получает это в свои руки.
Вместо того, чтобы быть в плену плана управления проектом, который они наметили в начале, гибкие методы управления проектами означали, что команды могли учитывать эти изменения для создания наилучшего продукта. Для этого им требовались более короткие циклы разработки (называемые спринтами), более итеративный процесс, а также непрерывная обратная связь и тестирование.
Затем, в 2001 году, группа разработчиков программного обеспечения собралась вместе, чтобы обсудить основные принципы Agile и по-настоящему углубиться в лежащую в его основе философию. Они придумали Манифест гибкой разработки программного обеспечения, набор ценностей и принципов, которые могли бы стать путеводной звездой для команд, задающихся вопросом, как стать гибкими.
Определение гибкого управления проектами
Если все это кажется очень ориентированным на разработку программного обеспечения, не беспокойтесь. Многие гибкие методологии управления проектами были разработаны с учетом программного обеспечения, но основные ценности и принципы гибкого управления проектами полезны для многих различных типов команд, от групп разработчиков до маркетинговых команд.
Знание истории гибкого управления проектами (или, по крайней мере, краткого изложения, изложенного выше) может помочь дать контекст некоторым терминам и процессам, которые до сих пор характеризуют гибкое управление проектами и которые мы вскоре рассмотрим более подробно. когда мы разберем Agile Manifesto более подробно.
Но если вы сейчас ищете просто определение гибкого управления проектами, а не предысторию того, что было раньше, вот полезное определение гибкого управления проектами.
Agile-управление проектами — это совместный итеративный подход к управлению проектами, который включает в себя непрерывное тестирование и способность реагировать на изменения.
Хорошо звучит? Давайте вернемся к Agile-манифесту, чтобы узнать больше об основных ценностях и принципах, которые вы можете использовать для руководства любым agile-проектом.
4 основных ценности Agile
Как упоминалось выше, самые ранние agile-методы управления проектами были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду.
Но не чувствуйте себя ограниченным этим.
Независимо от того, создаете ли вы программное обеспечение или что-то совершенно другое (например, маркетинговую кампанию), существует множество выводов, которые вы можете применить независимо от того, в какой отрасли вы работаете. значения:
Индивидуумы и взаимодействие над процессами и инструментами.
Работающее программное обеспечение с исчерпывающей документацией.
Сотрудничество с клиентами при заключении контракта.
Реагирование на переход по плану.
Эти основные ценности лежат в основе всех гибких подходов к управлению проектами, давая информацию обо всем, от стандартных способов работы до 12 гибких принципов управления проектами.
Из основных ценностей становится ясно, что гибкие подходы, прежде всего, основаны на сотрудничестве и управлении людьми.
Это относится не только к рабочим процессам (прогресс достигается за счет «людей и взаимодействий» и «сотрудничества с клиентами», ставя во главу угла человеческий фактор), но и к готовой продукции. То есть цель состоит в том, чтобы создать что-то функциональное, что принесет наибольшую пользу конечному пользователю.
12 принципов гибкого управления проектами
Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:
Приоритетом номер один является удовлетворение потребностей клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения.
Приветствуйте меняющиеся разработки, даже на поздних этапах разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
Работающее программное обеспечение является основным мерилом прогресса.
Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Когда дело доходит до дела, независимо от того, говорите ли вы о реальном программном обеспечении или используете его в качестве метафоры для всего, что вы создаете (давайте назовем это «Вещь»), гибкие методы побуждают вас создавать итерации « Вещь» быстро и часто — потому что «Вещь» лучше существовать в ущербной реальности, чем в совершенной теории.
Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.
Каковы преимущества гибкого управления проектами?
Agile-управление проектами может показаться просто модной методологией управления проектами du jour , но он зарекомендовал себя как нечто большее, чем просто вспышка.
Это потому, что результаты говорят сами за себя. Принципы Agile-управления проектами позволили командам всех типов работать более итеративно и гибко, давая им возможность адаптироваться к меняющимся требованиям проекта и быстрее выполнять поставленные задачи.
Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.
Больше адаптивности (и меньше рисков)
Одним из самых больших преимуществ гибких методов является возможность управлять меняющимися приоритетами. Благодаря итеративному подходу Agile и упору на непрерывную обратную связь вы можете получать необходимые данные в процессе разработки, а не после него, что позволяет команде делать более эффективные решения на основе реальных условий, а не только прогнозируемых условий.
А благодаря назначенным коротким циклам спринтов, более четкой визуализации проекта и регулярным обновлениям отчетов команды могут повысить предсказуемость проекта и снизить риски.
Повышение удовлетворенности клиентов
Возможно, вы помните, что сотрудничество с клиентами является одной из четырех основных ценностей гибкого управления проектами.
Что ж, одно из основных преимуществ этого заключается в том, что более тесное сотрудничество с клиентами приводит к большей удовлетворенности клиентов.
Гибкие методологии управления проектами выдвигают на первый план клиента и побуждают вас тесно сотрудничать с ним, а также с другими заинтересованными сторонами, чтобы убедиться, что вы создаете что-то, что действительно решает их проблему.
А поскольку agile-проекты включают в себя регулярное тестирование и обзор при каждом спринте, вы можете получать их реальную обратную связь в режиме реального времени при каждой итерации вашего работающего продукта.
Более счастливые команды
Agile-команды более автономны. То есть им часто предоставляется свобода предлагать новые идеи, вводить новшества и решать проблемы, которых может не хватать в традиционных методологиях управления проектами.
С такой ответственностью людям доверяют выполнение работы и поощряют видеть себя неотъемлемыми членами команды, которые могут внести ощутимый вклад в конечный результат проекта.
Не только это, но и акцент на сотрудничестве и общении может способствовать созданию более прозрачных, эффективных, творческих и, да, более счастливых команд.
Как стать гибкими
Более качественные результаты, большее число довольных клиентов и пользователей и повышение морального духа в коллективе — это может звучать слишком хорошо, чтобы быть правдой.
Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.
Для того чтобы гибкие методы оказали такое преобразующее воздействие, вам нужна поддержка, заинтересованность и несколько действительно выдающихся людей в команде.
Итак, если вам интересно, как стать гибким, вот что вам нужно иметь в виду.
Привлеките к работе нужных людей
Гибкие методологии управления проектами основаны на найме замечательных людей и предоставлении им возможности выполнять свою работу наилучшим образом. Это даже отражено в основных ценностях Agile: люди превыше процессов.
Это означает, что вам нужно сосредоточиться на подборе и найме нужных людей в первую очередь. Найдите нужных людей и высвободите их талант для решения проблем, а не бездумного выполнения приказов, и вы уже будете на полпути.
Как Teamwork использует Teamwork: рекрутинг и адаптация
Интеграция вашей службы поддержки и приложений для управления проектами — от найма до адаптации — позволяет создать бесшовный рабочий процесс и помогает кандидатам получать положительные впечатления от начала и до конца. Вот как мы используем Teamwork внутри компании и используем интеграцию между продуктами для создания плавного и прозрачного процесса на каждом этапе процесса найма.
Узнать больше
И найти нужных людей
бортовой
Согласно 13-му ежегодному отчету о состоянии Agile, все три главных препятствия на пути внедрения или масштабирования гибких методов управления проектами связаны с проблемами организационной культуры. К ним относятся:
Организационная культура, противоречащая ценностям Agile
Общее сопротивление организации изменениям
Неадекватная поддержка руководства и спонсорство от всех — включая руководство. Респонденты опроса высоко оценили внутренних agile-коучей, спонсорство руководителей, предоставляемые компанией программы обучения, последовательные практики и процессы в командах, а также внедрение общего инструмента в командах как 5 лучших советов, когда дело дошло до внедрения agile-методов управления проектами в компании.
Получите сертификацию
Существует распространенное заблуждение, что agile — это всего лишь бесплатность для всех, но это абсолютно не так. Agile — это не отсутствие методологии; это тип структуры сам по себе.
Если вы привержены гибкому управлению проектами, вы всегда можете инвестировать в получение сертификата по гибкому управлению проектами, чтобы узнать больше о гибких ценностях и принципах и понять, как они могут работать для вашей команды.
Используйте правильные инструменты управления проектами
Внедрение общего инструмента для команд является не только одним из 5 лучших способов масштабирования гибких практик, но и в первую очередь важно помочь вашей команде стать гибкими.
Ищите гибкое гибкое средство управления проектами, которое поддерживает ваш стиль работы, а не диктует его. В Teamwork есть все, что вам нужно, чтобы предоставить всем в вашей команде наглядность, гибкость и возможность совместной работы, необходимые им для продвижения вперед, независимо от того, предпочитаете ли вы доски Scrum или Kanban, — и когда придет время масштабироваться, он может масштабироваться вместе с вами.
Agile и Scrum: в чем разница?
Мы уже упоминали, сколько существует типов гибкого управления проектами (ответ: столько-то ), но из множества гибких методологий есть одна, которую вам, возможно, захочется освежить в памяти.
Scrum, несомненно, является одной из самых популярных гибких методологий, используемых сегодня: колоссальные 72% респондентов последнего отчета State of Agile заявили, что они используют «Scrum или гибрид, включающий Scrum».
Как и другие agile-методологии управления проектами, Scrum придерживается основных agile-ценностей и принципов (итераций, реакции на изменения и всего того хорошего, о чем говорилось выше).
Однако есть несколько специфичных для Scrum терминов и процессов, которые вам необходимо знать, если вы думаете о внедрении гибкого управления проектами с помощью Scrum.
Agile-управление проектами с помощью Scrum
В команде Scrum есть три основные роли:
Владелец продукта
Лицо, ответственное за максимизацию ценности работы, выполненной Командой Разработки. Один из способов сделать это — управлять бэклогом.
Команда разработчиков
Небольшая группа людей, которые в конечном итоге работают над The Thing. Команда имеет плоскую иерархию и самоорганизуется; как только цели установлены, члены команды могут решать их по своему усмотрению.
Scrum Master
Работает, чтобы облегчить и поддержать процесс Scrum для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.
Вот примерное представление о том, как это работает:
Все, что нужно сделать команде (например, все, что необходимо для продукта), перечисляется в бэклоге и ранжируется владельцем продукта в порядке приоритета. Задача Владельца Продукта состоит в том, чтобы оптимизировать работу Команды Разработки, следя за тем, чтобы Бэклог был лучшим из возможных (то есть четким, доступным и организованным для достижения успеха).
Scrum использует спринты фиксированной продолжительности (обычно несколько недель, всегда меньше месяца). У каждого спринта есть предопределенная цель спринта. Элементы из Бэклога идентифицируются и обрабатываются как часть каждого Спринта.
Прежде чем начнется спринт, вам нужно выполнить планирование спринта, чтобы выяснить, какова будет ваша цель спринта и как вы собираетесь ее достичь.
После начала Спринта Команда Разработки проводит короткую ежедневную встречу, называемую Ежедневным Скрамом, чтобы сообщить о прогрессе за предыдущий день, о том, на чем они будут сосредоточены сегодня, и обо всех выявленных рисках.
В конце каждого Спринта команда проводит Обзор Спринта (что-то вроде итогового собрания для Спринта), чтобы оценить свою работу и сообщить о следующем раунде Планирования Спринта.
Повторять, повторять, повторять.
Какая гибкая методология мне подходит?
Если вы все еще пытаетесь решить, какую методологию выбрать — Agile, Scrum, Kanban, Scrumban или какой-то другой гибрид? — помните, что вы можете начать с заимствования принципов и процессов, которые имеют смысл для вас и вашей команды.
Гибкое управление проектами. Руководство для начинающих
Когда дело доходит до управления вашей работой, существуют десятки и десятков методологий управления проектами на выбор.
Но когда вы начнете исследовать, какая методология подходит именно вам, вы, вероятно, снова и снова увидите одно конкретное слово:
Agile.
Кажется, что это мерцает в вашем периферийном зрении, как какой-то мираж управления проектами. Это реально? Могут ли все общепризнанные преимущества гибкого управления проектами быть правдой? Или это просто модное словечко, которое обещает больше, чем дает?
Можно с уверенностью сказать, что вокруг преимуществ гибкого управления проектами много шума. Но что именно? И как узнать, подходит ли это для управления вашей командой?
Что такое гибкое управление проектами?
Agile-управление проектами — это итеративный подход к проектам разработки программного обеспечения, обеспечивающий быстрое реагирование на обратную связь и возможность внесения соответствующих изменений на каждом этапе спринта или цикла продукта.
Это позволяет проектным группам применять гибкие методологии управления проектами для быстрой и совместной работы в рамках временных рамок и бюджета проекта.
Простой в использовании, мощный, когда вам это нужно
Teamwork, которому доверяют 20 000 компаний и 6 000 агентств, позволяет легко управлять, отслеживать и настраивать несколько сложных проектов. Начните с бесплатной 30-дневной пробной версии.
Попробуйте Teamwork бесплатно
Гибкое управление проектами охватывает множество различных гибких методологий управления проектами, каждая из которых основана на некоторых общих принципах и основных ценностях гибкой разработки.
Но единой универсальной «гибкой методологии» не существует. Так откуда они все взялись?
Краткая история Agile
Большинство современных гибких методов управления проектами берут свое начало в разработке программного обеспечения. Еще в 1990-х команда разработчиков программного обеспечения обнаружила, что высокоструктурированные «тяжеловесные» традиционные методологии управления проектами (например, Waterfall) просто не подходят, когда дело доходит до того, как им нужно работать.
Они обнаружили, что подводные камни этих тяжеловесных методов, такие как отсутствие гибкости, приспособляемости и даже автономии, затрудняли их реакцию на изменения или применение полученных знаний в ходе работы. Поскольку планы проекта были намечены в самом начале, не было места для неожиданностей, а отклонения могли дорого обойтись.
Но в отличие от отраслей, где процесс был фиксированным, а результат был надежным и стабильным (подумайте: производственный процесс, который создает один и тот же продукт на сборочной линии), изменения являются фундаментальным компонентом программных проектов.
Может быть, требования заинтересованных сторон меняются, или, может быть, тестирование показывает, что что-то работает не так, как должно, когда конечный пользователь получает это в свои руки.
Вместо того, чтобы быть в плену плана управления проектом, который они наметили в начале, гибкие методы управления проектами означали, что команды могли учитывать эти изменения для создания наилучшего продукта. Для этого им требовались более короткие циклы разработки (называемые спринтами), более итеративный процесс, а также непрерывная обратная связь и тестирование.
Затем, в 2001 году, группа разработчиков программного обеспечения собралась вместе, чтобы обсудить основные принципы Agile и по-настоящему углубиться в лежащую в его основе философию. Они придумали Манифест гибкой разработки программного обеспечения, набор ценностей и принципов, которые могли бы стать путеводной звездой для команд, задающихся вопросом, как стать гибкими.
Определение гибкого управления проектами
Если все это кажется очень ориентированным на разработку программного обеспечения, не беспокойтесь. Многие гибкие методологии управления проектами были разработаны с учетом программного обеспечения, но основные ценности и принципы гибкого управления проектами полезны для многих различных типов команд, от групп разработчиков до маркетинговых команд.
Знание истории гибкого управления проектами (или, по крайней мере, краткого изложения, изложенного выше) может помочь дать контекст некоторым терминам и процессам, которые до сих пор характеризуют гибкое управление проектами и которые мы вскоре рассмотрим более подробно. когда мы разберем Agile Manifesto более подробно.
Но если вы сейчас ищете просто определение гибкого управления проектами, а не предысторию того, что было раньше, вот полезное определение гибкого управления проектами.
Agile-управление проектами — это совместный итеративный подход к управлению проектами, который включает в себя непрерывное тестирование и способность реагировать на изменения.
Хорошо звучит? Давайте вернемся к Agile-манифесту, чтобы узнать больше об основных ценностях и принципах, которые вы можете использовать для руководства любым agile-проектом.
4 основных ценности Agile
Как упоминалось выше, самые ранние agile-методы управления проектами были сосредоточены на программном обеспечении, и Agile Manifesto был создан разработчиками программного обеспечения. Таким образом, вы увидите это слово и другие связанные с ним термины, такие как «разработчики» и «клиенты», повсюду.
Но не чувствуйте себя ограниченным этим.
Независимо от того, создаете ли вы программное обеспечение или что-то совершенно другое (например, маркетинговую кампанию), существует множество выводов, которые вы можете применить независимо от того, в какой отрасли вы работаете. значения:
Индивидуумы и взаимодействие над процессами и инструментами.
Работающее программное обеспечение с исчерпывающей документацией.
Сотрудничество с клиентами при заключении контракта.
Реагирование на переход по плану.
Эти основные ценности лежат в основе всех гибких подходов к управлению проектами, давая информацию обо всем, от стандартных способов работы до 12 гибких принципов управления проектами.
Из основных ценностей становится ясно, что гибкие подходы, прежде всего, основаны на сотрудничестве и управлении людьми.
Это относится не только к рабочим процессам (прогресс достигается за счет «людей и взаимодействий» и «сотрудничества с клиентами», ставя во главу угла человеческий фактор), но и к готовой продукции. То есть цель состоит в том, чтобы создать что-то функциональное, что принесет наибольшую пользу конечному пользователю.
12 принципов гибкого управления проектами
Согласно Agile Manifesto, существует 12 ключевых принципов гибкого управления проектами. По словам самого манифеста, это:
Приоритетом номер один является удовлетворение потребностей клиентов за счет раннего и непрерывного предоставления ценного программного обеспечения.
Приветствуйте меняющиеся разработки, даже на поздних этапах разработки. Гибкие процессы используют изменения для конкурентного преимущества клиента.
Доставляйте работающее программное обеспечение часто, от нескольких недель до нескольких месяцев, предпочитая более короткие сроки.
Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
Создавайте проекты вокруг целеустремленных людей. Обеспечьте им необходимые условия и поддержку и доверьте им выполнение работы.
Самый эффективный и действенный метод передачи информации команде разработчиков и внутри нее — беседа лицом к лицу.
Работающее программное обеспечение является основным мерилом прогресса.
Гибкие процессы способствуют устойчивому развитию. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок.
Постоянное внимание к техническому совершенству и хорошему дизайну повышает маневренность.
Простота — искусство максимального увеличения объема незавершенной работы — имеет важное значение.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами.
Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.
Когда дело доходит до дела, независимо от того, говорите ли вы о реальном программном обеспечении или используете его в качестве метафоры для всего, что вы создаете (давайте назовем это «Вещь»), гибкие методы побуждают вас создавать итерации « Вещь» быстро и часто — потому что «Вещь» лучше существовать в ущербной реальности, чем в совершенной теории.
Еще одна повторяющаяся тема в этих принципах? Выровняйтесь, оставайтесь в согласии и работайте вместе. Это касается всех участников: вашей собственной команды, «деловых людей», других отделов и заинтересованных сторон. Гибкие методы управления проектами основаны на активном сотрудничестве и прочных межличностных отношениях. Итак, как однажды сказали Билл и/или Тед: будьте добры друг к другу.
Каковы преимущества гибкого управления проектами?
Agile-управление проектами может показаться просто модной методологией управления проектами du jour , но он зарекомендовал себя как нечто большее, чем просто вспышка.
Это потому, что результаты говорят сами за себя. Принципы Agile-управления проектами позволили командам всех типов работать более итеративно и гибко, давая им возможность адаптироваться к меняющимся требованиям проекта и быстрее выполнять поставленные задачи.
Вот некоторые из наиболее часто упоминаемых преимуществ гибкого управления проектами.
Больше адаптивности (и меньше рисков)
Одним из самых больших преимуществ гибких методов является возможность управлять меняющимися приоритетами. Благодаря итеративному подходу Agile и упору на непрерывную обратную связь вы можете получать необходимые данные в процессе разработки, а не после него, что позволяет команде делать более эффективные решения на основе реальных условий, а не только прогнозируемых условий.
А благодаря назначенным коротким циклам спринтов, более четкой визуализации проекта и регулярным обновлениям отчетов команды могут повысить предсказуемость проекта и снизить риски.
Повышение удовлетворенности клиентов
Возможно, вы помните, что сотрудничество с клиентами является одной из четырех основных ценностей гибкого управления проектами.
Что ж, одно из основных преимуществ этого заключается в том, что более тесное сотрудничество с клиентами приводит к большей удовлетворенности клиентов.
Гибкие методологии управления проектами выдвигают на первый план клиента и побуждают вас тесно сотрудничать с ним, а также с другими заинтересованными сторонами, чтобы убедиться, что вы создаете что-то, что действительно решает их проблему.
А поскольку agile-проекты включают в себя регулярное тестирование и обзор при каждом спринте, вы можете получать их реальную обратную связь в режиме реального времени при каждой итерации вашего работающего продукта.
Более счастливые команды
Agile-команды более автономны. То есть им часто предоставляется свобода предлагать новые идеи, вводить новшества и решать проблемы, которых может не хватать в традиционных методологиях управления проектами.
С такой ответственностью людям доверяют выполнение работы и поощряют видеть себя неотъемлемыми членами команды, которые могут внести ощутимый вклад в конечный результат проекта.
Не только это, но и акцент на сотрудничестве и общении может способствовать созданию более прозрачных, эффективных, творческих и, да, более счастливых команд.
Как стать гибкими
Более качественные результаты, большее число довольных клиентов и пользователей и повышение морального духа в коллективе — это может звучать слишком хорошо, чтобы быть правдой.
Но вот в чем дело: гибкое управление проектами — это не волшебное панацея, способная решить все ваши проблемы с управлением проектами. И он не существует на пустом месте.
Для того чтобы гибкие методы оказали такое преобразующее воздействие, вам нужна поддержка, заинтересованность и несколько действительно выдающихся людей в команде.
Итак, если вам интересно, как стать гибким, вот что вам нужно иметь в виду.
Привлеките к работе нужных людей
Гибкие методологии управления проектами основаны на найме замечательных людей и предоставлении им возможности выполнять свою работу наилучшим образом. Это даже отражено в основных ценностях Agile: люди превыше процессов.
Это означает, что вам нужно сосредоточиться на подборе и найме нужных людей в первую очередь. Найдите нужных людей и высвободите их талант для решения проблем, а не бездумного выполнения приказов, и вы уже будете на полпути.
Как Teamwork использует Teamwork: рекрутинг и адаптация
Интеграция вашей службы поддержки и приложений для управления проектами — от найма до адаптации — позволяет создать бесшовный рабочий процесс и помогает кандидатам получать положительные впечатления от начала и до конца. Вот как мы используем Teamwork внутри компании и используем интеграцию между продуктами для создания плавного и прозрачного процесса на каждом этапе процесса найма.
Узнать больше
И найти нужных людей
бортовой
Согласно 13-му ежегодному отчету о состоянии Agile, все три главных препятствия на пути внедрения или масштабирования гибких методов управления проектами связаны с проблемами организационной культуры. К ним относятся:
Организационная культура, противоречащая ценностям Agile
Общее сопротивление организации изменениям
Неадекватная поддержка руководства и спонсорство от всех — включая руководство. Респонденты опроса высоко оценили внутренних agile-коучей, спонсорство руководителей, предоставляемые компанией программы обучения, последовательные практики и процессы в командах, а также внедрение общего инструмента в командах как 5 лучших советов, когда дело дошло до внедрения agile-методов управления проектами в компании.
Получите сертификацию
Существует распространенное заблуждение, что agile — это всего лишь бесплатность для всех, но это абсолютно не так. Agile — это не отсутствие методологии; это тип структуры сам по себе.
Если вы привержены гибкому управлению проектами, вы всегда можете инвестировать в получение сертификата по гибкому управлению проектами, чтобы узнать больше о гибких ценностях и принципах и понять, как они могут работать для вашей команды.
Используйте правильные инструменты управления проектами
Внедрение общего инструмента для команд является не только одним из 5 лучших способов масштабирования гибких практик, но и в первую очередь важно помочь вашей команде стать гибкими.
Ищите гибкое гибкое средство управления проектами, которое поддерживает ваш стиль работы, а не диктует его. В Teamwork есть все, что вам нужно, чтобы предоставить всем в вашей команде наглядность, гибкость и возможность совместной работы, необходимые им для продвижения вперед, независимо от того, предпочитаете ли вы доски Scrum или Kanban, — и когда придет время масштабироваться, он может масштабироваться вместе с вами.
Agile и Scrum: в чем разница?
Мы уже упоминали, сколько существует типов гибкого управления проектами (ответ: столько-то ), но из множества гибких методологий есть одна, которую вам, возможно, захочется освежить в памяти.
Scrum, несомненно, является одной из самых популярных гибких методологий, используемых сегодня: колоссальные 72% респондентов последнего отчета State of Agile заявили, что они используют «Scrum или гибрид, включающий Scrum».
Как и другие agile-методологии управления проектами, Scrum придерживается основных agile-ценностей и принципов (итераций, реакции на изменения и всего того хорошего, о чем говорилось выше).
Однако есть несколько специфичных для Scrum терминов и процессов, которые вам необходимо знать, если вы думаете о внедрении гибкого управления проектами с помощью Scrum.
Agile-управление проектами с помощью Scrum
В команде Scrum есть три основные роли:
Владелец продукта
Лицо, ответственное за максимизацию ценности работы, выполненной Командой Разработки. Один из способов сделать это — управлять бэклогом.
Команда разработчиков
Небольшая группа людей, которые в конечном итоге работают над The Thing. Команда имеет плоскую иерархию и самоорганизуется; как только цели установлены, члены команды могут решать их по своему усмотрению.
Scrum Master
Работает, чтобы облегчить и поддержать процесс Scrum для Владельца Продукта, Команды Разработки и, что важно, для организации в целом.
Вот примерное представление о том, как это работает:
Все, что нужно сделать команде (например, все, что необходимо для продукта), перечисляется в бэклоге и ранжируется владельцем продукта в порядке приоритета. Задача Владельца Продукта состоит в том, чтобы оптимизировать работу Команды Разработки, следя за тем, чтобы Бэклог был лучшим из возможных (то есть четким, доступным и организованным для достижения успеха).
Scrum использует спринты фиксированной продолжительности (обычно несколько недель, всегда меньше месяца).
No related posts.

Знакомство с agile-управлением проектами | Atlassian

Просмотр тем

Что такое управление проектами по методике agile?

Статьи об agile-управлении проектами

История

Принципы работы Scrum

Четыре составляющих Scrum

Scrum-доска

Принципы работы Kanban

Четыре компонента Kanban

Kanban-доска

Оцените, запишите и распланируйте

Оценка проекта по методике agile

Agile-отчеты

Бэклог: ведение и управление

Топ-7 методов управления проектами: Scrum, Kanban, PRINCE2..

08 Июл 2016

Почему «управление проектами»?

Краткая история проектного управления

Популярные системы управления проектами

Классическое проектное управление

Agile

Scrum

Lean

Kanban

6 сигм (Six Sigma)

PRINCE2

Лучшая система управления проектами … для Вас!

Как получить международный сертификат по Agile?

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

Метод Agile: определение и краткая история

Манифест Agile

Ключевые моменты в применении Agile

Популярные методы управления проектами

Метод Scrum

Метод Kanban

Плюсы и минусы Agile

Внедрение Agile

Заключение

Легендарный agile: в чём его суть и чем он полезен в управлении проектами

Оглавление

Agile — что это такое

Преимущества и недостатки Agile

Преимущества

Недостатки

Ценности Agile

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

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

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

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

12 принципов Agile

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

Изменения приветствуются

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

Поддержка контакта между командой и заказчиком

Мотивация сотрудников

Простота общения с командой и внутри неё

Самоорганизация и самоконтроль команды

Постоянный темп работы

Максимальное упрощение решений, процессов и документации

Непрерывное улучшение

Постоянный анализ и поиск возможностей оптимизации

Работающий продукт — главный показатель прогресса

Методы Scrum и Kanban в Agile

Scrum

Kanban

Какие компании используют гибкую методологию

Мир

Россия

Книги об Agile

Заключение

Agile методология — принципы Agile управления проектами

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

Что такое Agile

Манифест

12 принципов Agile

Главные отличия от Scrum и Kanban

Плюсы и минусы

Как внедрить Agile в работу компании

Книги про Agile