Agile и Scrum на практике вопросы скрам-мастеру


Содержание

Взаимодействие Скрам Мастера и Владельца Продукта

Ни для кого не секрет, что Скрам Мастер и Владелец Продукта — две отдельные роли, которые дополняют друг друга, и никто не может их совмещать. К сожалению, в реальной жизни случается, что Скрам Мастер не поддерживает Владельца Продукта, частично выполняет его обязанности, или Скрам Мастера нет вовсе. Эта статья — о том, как организовать продуктивное взаимодействие людей в этих двух ролях в команде: о разнице между ними (Scrum Master vs Product Owner), а также о том, каких действий им ждать друг от друга.

Владелец Продукта и Скрам Мастер

В материалах экспертов по Скраму за словами “difference between Scrum Master and Product Owner” (разница между Скрам Мастером и Владельцем Продукта) стоит грустная правда: если кто-то один не действует в своей роли эффективно, другому придется страдать.

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

В серый круг на этой схеме взята Скрам команда, состоящая из Владельца Продукта, Скрам Мастера и кросс-функциональной Команды разработки.

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

Успех в роли как Скрам Мастера, так и Владельца Продукта требует адекватных навыков, времени, усилий и сфокусированности. Совмещать эти две роли (когда человек тот самый несчастный Product Owner and Scrum Master) — не только тяжело, но и неминуемо ведет к тому, что некоторые важные обязанности не будут выполнены. Если вы Владелец Продукта, оставьте в покое обязанности Скрам Мастера!

Чего Владелец Продукта может ожидать от Скрам Мастера

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

Коучинг команды

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

Организационные изменения

  • Работает с топ-менеджментом, HR-специалистами и другими бизнес-группами над необходимыми для Скрама организационными изменениями.
  • Объясняет стейкхолдерам, что дает Скрам и чем отличается от прежнего способа работы, показывает их роль в Аджайл-процессе, обеспечивает их поддержку и лояльность.
  • Разрешает конфликты между разными ролями, например Владельцем Продукта и продакт-менеджером или проджект-менеджером.

Коучинг Владельца Продукта

  • Помогает Владельцу Продукта выбрать нужные техники и инструменты продакт-менеджмента.
  • Поддерживает Владельца Продукта в принятии решений о продукте и вопросах власти и влияния.
  • Помогает утвердить в организации Аджайл-практики продакт-менеджмента.

Скрам Мастер поддерживает Владельца Продукта так, чтобы тот/та смог/ла сфокусироваться на своей работе: обеспечить разработку нужного продукта с нужным пользовательским опытом (UX) и нужными фичами. Если такой поддержки Скрам Мастер оказать не может, с ним/ней надо поговорить и узнать, в чем дело. Владельцу Продукта не стоит проявлять избыточную инициативу и брать на себя работу Скрам Мастера. Если у вас нет Скрам Мастера, покажите руководителю список его обязанностей и объясните, почему такая роль нужна в команде.

Чего Скрам Мастер может ожидать от Владельца Продукта

Рука руку моет, так что и у Скрам Мастера есть некоторые ожидания по работе Владельца Продукта. Вот какие они, по списку.

Вижен и стратегия

  • Формулирует для команды вижен — видение того, как будет развиваться продукт.
  • Объясняет особенности рынка, торговое предложение и бизнес-цели продукта.
  • Ставит цели для продукта и релиза на ближайшее время (например, полгода).

Работа над продуктом

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

Сотрудничество

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

Переведено и адаптировано командой BrainRain по статье Романа Пихлера Every Great Product Owner Needs a Great Scrum Master

Посмотрите наши ближайшие тренинги для Скрам Мастеров и Владельцев Продуктов — Сертификационные тренинги от BrainRain

Scrum и Agile для чайников

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

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

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

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

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

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

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.

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

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

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

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

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

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

  • участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
  • продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
  • скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
    Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.

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

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


Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

  • что я сделал вчера
  • что я сделаю сегодня
  • что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Метод управления проектами SCRUM

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

Какие методы существуют?

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

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

Классические

К классическим относится модель WATERFALL (или водопад). В данной модели этапы идут строго друг за другом:

  1. Инициализация
  2. Планирование и составление полной документации проекта
  3. Разработка проекта
  4. Тестирование
  5. Завершение

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

Гибкие

Гибкие или революционные методы управления — это все методы, построенные на базе AGILE. AGILE определяет ценности и принципы, которым руководствуются участники команд.

Наиболее популярным и эффективным фреймворком разработки проектов по методам AGILE является SCRUM. Про него сегодня и пойдет речь.

Почему гибкость побеждает в IT проектах?

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

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

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

Почему SCRUM?

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

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

Внедрение метода управления проектами SCRUM подходит для команд разработки от 3 до 9 человек. А для больших проектов существует Scrum of Scrums, где несколько Scrum команд объединены для достижения единой цели.

Именно поэтому Scrum получил такое распространение.

3 роли в SCRUM TEAM

Scrum team делится на 3 роли:

  1. Development Team — команда разработки
  2. Product Owner — связующий между заказчиком и командой разработки
  3. Scrum Master — помощник, устраняющий проблемы внутри Scrum team

Взаимодействия в SCRUM TEAM

Взаимодействия в SCRUM:

  1. Планирование — совещание где разбирается что необходимо сделать в текущем спринте. Проводится вначале каждой итерации.
  2. Daily Scrum Meeting — Ежедневное совещание длительностью порядка 15 минут.
  3. Sprint Review Meeting — демонстрация функционала по завершению итерации.
  4. Sprint Retrospective Meeting — смотрим на результат команды

3 SCRUM вопроса

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

  1. Что я сделал для того чтобы приблизить команду к цели спринта?
  2. Что я сделаю сегодня для того чтобы приблизить команду к цели спринта?
  3. Какие препятствия стоят на моем пути?

Внедрение SCRUM

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

Задачи SCRUM

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

Заключение

Теория SCRUM проста. Основная сложность заключается в применении метода управления проектами SCRUM на практике.

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

Как использовать Agile и Scrum для управления проектами

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

Для чего внедрять гибкие методологии

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

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

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

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

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Начните с бэклога

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

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

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

Внедряйте спринты

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

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

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

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

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

Распределите роли в команде

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

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

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

Люди, которые непосредственно создают и тестируют код.

К разработчикам есть несколько требований:

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


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

Контролируйте процессы

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Контролируйте работу команды с помощью двух scrum-показателей:

  • Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
  • Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

Организуйте работу команды

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

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • Какие есть проблемы и препятствия для выполнения задач?
Цукерберг рекомендует:  Рекурсия - Создание корректной (возможно рекурсивной) функции

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

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

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

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

Демонстрируйте проект

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

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

Изучите инструменты для контроля

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

  • Trello — подходит для маленьких проектов, быстро и удобно.
  • Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
  • Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.

Чек-лист — как начать использовать Agile и Scrum на проекте

  • Научиться вести бэклог и расставлять приоритеты.
  • Проводить спринты.
  • Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
  • Контролировать работу с помощью диаграммы сгорания проекта.
  • Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
  • После каждого спринта демонстрировать проект.
  • Изучить инструменты и найти самый удобный.

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

Ключевые обязанности Scrum-мастера

Работа Скрам-мастера – полная занятость или же её можно совмещать?

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

Ниже кратко приведены десять основных обязанностей, на которых хороший Scrum-мастер фокусируется ежедневно:

1. Выполнение Скрам процесса

Он знает и понимает Scrum, обучает ему команду, а также всех окружающих проект.

Он помогает команде корректно использовать каркас Scrum и получать выгоды от идей эмпирической разработки продуктов.

2. Фасилитация командных встреч

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

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

Это вторая важнейшая ответственность Скрам-мастера. Он – мастер взаимодействия.

3. Проведение ретроспектив

У Скрам команды есть одна самая важная встреча – ретроспектива спринта. Сам факт наличия большого количества книг по этой теме подтверждает её важность.

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

Поэтому без непрерывного критического рассмотрения и адаптации текущего процесса, команда застрянет в посредственности – “как-то что-то иногда работает, ну и ладно”.

4. Донесение «большой картинки» до команды

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

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

5. Поиск ценности продукта

Хороший ScrumMaster уделяет время коучингу и менторству Владельца продукта (и других продуктоводов компании), чтобы они освоили такие инструменты как Lean Startup, Lean UX, Customer Development. Но для этого, конечно, необходимо, чтобы Скрам-мастер прежде освоил их сам.

6. Личный коучинг членов команды разработки

Индивидуальный коучинг (например, модель Сo-active coaching model) – ещё одна из жизненно необходимых способностей, которые стоит освоить Скрам-мастеру.

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

7. Усиление обучения на всех уровнях

8. Изменение среды

Есть поговорка: «Поменяйте компанию или … поменяйте компанию».

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

9. Лавирование между конфликтами

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

И что, вы думаете, случится, когда они надумают вдруг заговорить друг с другом? Они начнут делиться своими мыслями, опасениями, надеждами, идеями. Это несомненно то, чего мы так хотим – помочь людям начать общаться и строить общую картину (если не мира, то хотя бы текущего проекта).

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

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

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

10. Отзеркаливание и катализация роста

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

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

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

Чтобы быть Scrum-мастером, мало просто выполнять основные обязанности.

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

Agile, scrum, kanban: в чем разница и для чего использовать?

Главный редактор Rusbase

Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?

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

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

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

К отдельным agile-подходам относятся scrum и kanban.

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


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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

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

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

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

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.

Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.

Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.

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

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.

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

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

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

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

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Что почитать по теме?

  1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
  2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
  3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
  4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
  5. K. Schwaber, J. Sutherland “The Scrum Guide”
  6. M. Cohn “Agile estimating and planning”

Текст: Александр Петров.

Видео по теме:

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Обзор методологии Scrum

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

Роли
В методологии Scrum всего три роли:

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

  • Создает атмосферу доверия
  • Участвует в митингах в качестве фасилитатора
  • Устраняет препятствия
  • Делает проблемы и открытые вопросы видимыми
  • Отвечает за соблюдение практик и процесса в команде

Скрам Мастер ведет Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте. ScrumMaster может также помогать Product Owner создавать Backlog для команды.

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

  • Отвечает за формирование product vision
  • УправляетROI
  • Управляет ожиданиями заказчиков и всех заинтересованных лиц
  • Координирует и приоритизирует Product backlog
  • Предоставляет понятные и тестируемые требования команде
  • Взаимодействует с командой и заказчиком
  • Отвечает за приемку кода в конце каждой итерации

Product Owner ставит задачи команде, но он не вправе ставить задачи конкретному члену проектной команды в течении спринта.

  • Отвечает за оценку элементов баклога
  • Принимает решение по дизайну и имплементации
  • Разрабатывает софт и предоставляет его заказчику
  • Отслеживает собственный прогресс (вместе со Скрам Мастером)
  • Отвечает за результат перед Product Owner

Размер команды ограничивается размером группы людей, способных эффективно взаимодействовать лицом к лицу. Типичные размер команды – 7 плюс минус 2.

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

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

Product Backlog постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты. За Product Backlog отвечает Product Owner. Он также работает совместно с командой для того, чтобы получить приближенную оценку на выполнение элементов Product Backlog для того, чтобы более точно расставлять приоритеты в соответствии с необходимым временем на выполнение.

Сумма оценок оставшейся работы может быть построена как график зависимости от времени. Такой график называется Sprint Burndown chart. Он демонстрирует прогресс команды по ходу спринта.

Спринт (Sprint)
В Scrum итерация называется Sprint. Ее длительность составляет 1 месяц (30 дней). Результатом Sprint является готовый продукт (build), который можно передавать (deliver) заказчику (по крайней мере, система должна быть готова к показу заказчику). Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта и предлагая улучшения к созданной функциональности.

Такие улучшения попадают в Product Backlog, приоритезируются наравне с прочими требованиями и могут быть запланированы на следующий (или на один из следующих) спринтов. Каждый спринт представляет собой маленький «водопад». В течение спринта делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что Sprint Backlog не может быть изменен никем, кроме команды.

  • Жизненный цикл спринта
  • Планирование спринта

В начале каждого спринта проводится планирование спринта. В планировании спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Планирование спринта состоит из двух последовательных митингов.

Планирование спринта, митинг первый. Участники: команда, Product Onwer, Sxrum Master, пользователи, менеджемент Цель: Определить цель спринта (Sprint Goal) и Sprint Backlog –функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта. Артефакт: Sprint Backlog.

Планирование спринта, митинг второй. Участники: Скрам Мастер, команда Цель: определить, как именно будет разрабатываться определенная функциональность для того, чтобы достичь цели спринта. Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. Артефакт: в Sprint Backlog появляются задачи Если в ходе спринта выясняется, что команда не может успеть сделать запланированное на спринт, то Скрам Мастер, Product Owner и команда встречаются и выясняют, как можно сократить scope работ и при этом достичь цели спринта.

Остановка спринта (Sprint Abnormal Termination)

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

Daily Scrum Meeting

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

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • С какими проблемами столкнулся?

Скрам Мастер собирает все открытые для обсуждения вопросы в виде Action Items, например в формате что/кто/когда:

  • Обсудить проблему с отрисовкой контрола
  • Петя и Вася
  • Сразу после скрама

Демо и ревью спринта
Рекомендованная длительность: 4 часа Команда демонстрирует инкремент продукта, созданный за последний спринт. Product Owner, менеджмент, заказчики, пользователи в свою очередь его оценивают. Команда рассказывает о поставленных задачах, о том как они были решены, какие препятвия были у них на пути, какие были приняты решения, какие проблемы остались нерешенными.

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

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

Scrum за пять минут

Согласно недавним исследованиям, около 90% зарубежных ИТ-компаний предпочитают Scrum для управления своими проектами. Среди них Microsoft, Yahoo, Google, IBM, Amazon, BBC, а также Philips, Siemens, Nokia и многие другие. О том, что из себя представляет данная методология и в чем причина ее успеха, рассказывает старший инженер по тестированию компании «Аплана» — Ксения Квакова.

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

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

Agile (с англ. «гибкий», «подвижный», «быстрый») — это система ценностей. «Внедрить» Agile нельзя, ведь ценности можно лишь предложить людям, максимум — привить их. Придерживаясь каких-то убеждений, разделяя некие принципы, можно проецировать их на любые свои действия (и на любой вид коллективной деятельности). На основе Agile развивается целый комплекс подходов, но самая распространенная практика в управлении проектами — Scrum (Скрам).

Четыре ценности и 12 принципов Agile подробно описаны в Agile-манифесте, а узнать больше об Agile можно из предыдущей статьи в блоге «Апланы» — «Agile и управление проектами».

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

Чтобы объяснить суть подхода, создатели Scrum (и одни из создателей Agile) Кен Швабер и Джефф Сазерленд разработали «Исчерпывающее руководство по Скраму», в котором описали основные «правила игры», а затем дополняли его на протяжении более двадцати лет. Конечно, Scrum не стоит на месте, а продолжает развиваться. Но в чем же его суть? В чем причина его успеха?!

Scrum: теория и ценности

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


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

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

Scrum компактный, простой для понимания, но трудный для совершенного овладения. Он основан на теории эмпирического управления, согласно которой источником знаний является не что иное, как опыт, а источником решений — реальные данные. Процесс эмпирического управления основан на «трех китах»: прозрачности, инспекции и адаптации.

Команда в Scrum опирается на несколько ценностей: преданность, смелость, сфокусированность, открытость и уважение.

Суть Scrum — в маленькой команде людей

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

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

По словам создателей фреймворка, суть Scrum — в маленькой команде людей. Они поясняют это так: «Каждая отдельная команда чрезвычайно гибка и адаптивна. Эти преимущества проявляются, распространяясь на любое количество команд в организации: одну, несколько или целые сети команд, которые разрабатывают, выпускают, осуществляют эксплуатацию и поддержку продуктов, таким образом объединяя труд тысяч людей».

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

Джефф Безос — основатель компаний Amazon и Blue Origin, владелец The Washington Post и богатейший человек в мире (Forbes, 2020) — приверженец Scrum. Он сформулировал простое и очень наглядное правило: команда должна быть достаточно маленькой, чтобы ее можно было накормить двумя пиццами. «Правило двух пицц», внедренное в Amazon, идеально соотносится с философией Scrum — именно таким количеством можно накормить от четырех до восьми человек.

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

Роли в Скраме

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

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

Владелец продукта — это человек-промежуточное звено между заказчиком и командой разработки (может быть на той и на другой стороне). Он несет ответственность за достижение максимальной ценности продукта.

События Скрама

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

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

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

Взаимодействие Скрам Мастера и Владельца Продукта

Ни для кого не секрет, что Скрам Мастер и Владелец Продукта — две отдельные роли, которые дополняют друг друга, и никто не может их совмещать. К сожалению, в реальной жизни случается, что Скрам Мастер не поддерживает Владельца Продукта, частично выполняет его обязанности, или Скрам Мастера нет вовсе. Эта статья — о том, как организовать продуктивное взаимодействие людей в этих двух ролях в команде: о разнице между ними (Scrum Master vs Product Owner), а также о том, каких действий им ждать друг от друга.

Владелец Продукта и Скрам Мастер

В материалах экспертов по Скраму за словами “difference between Scrum Master and Product Owner” (разница между Скрам Мастером и Владельцем Продукта) стоит грустная правда: если кто-то один не действует в своей роли эффективно, другому придется страдать.

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

В серый круг на этой схеме взята Скрам команда, состоящая из Владельца Продукта, Скрам Мастера и кросс-функциональной Команды разработки.

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

Успех в роли как Скрам Мастера, так и Владельца Продукта требует адекватных навыков, времени, усилий и сфокусированности. Совмещать эти две роли (когда человек тот самый несчастный Product Owner and Scrum Master) — не только тяжело, но и неминуемо ведет к тому, что некоторые важные обязанности не будут выполнены. Если вы Владелец Продукта, оставьте в покое обязанности Скрам Мастера!

Чего Владелец Продукта может ожидать от Скрам Мастера

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

Коучинг команды

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

Организационные изменения

  • Работает с топ-менеджментом, HR-специалистами и другими бизнес-группами над необходимыми для Скрама организационными изменениями.
  • Объясняет стейкхолдерам, что дает Скрам и чем отличается от прежнего способа работы, показывает их роль в Аджайл-процессе, обеспечивает их поддержку и лояльность.
  • Разрешает конфликты между разными ролями, например Владельцем Продукта и продакт-менеджером или проджект-менеджером.

Коучинг Владельца Продукта

  • Помогает Владельцу Продукта выбрать нужные техники и инструменты продакт-менеджмента.
  • Поддерживает Владельца Продукта в принятии решений о продукте и вопросах власти и влияния.
  • Помогает утвердить в организации Аджайл-практики продакт-менеджмента.

Скрам Мастер поддерживает Владельца Продукта так, чтобы тот/та смог/ла сфокусироваться на своей работе: обеспечить разработку нужного продукта с нужным пользовательским опытом (UX) и нужными фичами. Если такой поддержки Скрам Мастер оказать не может, с ним/ней надо поговорить и узнать, в чем дело. Владельцу Продукта не стоит проявлять избыточную инициативу и брать на себя работу Скрам Мастера. Если у вас нет Скрам Мастера, покажите руководителю список его обязанностей и объясните, почему такая роль нужна в команде.

Чего Скрам Мастер может ожидать от Владельца Продукта

Рука руку моет, так что и у Скрам Мастера есть некоторые ожидания по работе Владельца Продукта. Вот какие они, по списку.

Вижен и стратегия

  • Формулирует для команды вижен — видение того, как будет развиваться продукт.
  • Объясняет особенности рынка, торговое предложение и бизнес-цели продукта.
  • Ставит цели для продукта и релиза на ближайшее время (например, полгода).

Работа над продуктом

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

Сотрудничество

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

Переведено и адаптировано командой BrainRain по статье Романа Пихлера Every Great Product Owner Needs a Great Scrum Master

Посмотрите наши ближайшие тренинги для Скрам Мастеров и Владельцев Продуктов — Сертификационные тренинги от BrainRain

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

08 Июл 2020

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

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

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

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

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

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

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

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

  • Классический проектный менеджмент
  • Agile
  • Scrum
  • Lean
  • Kanban
  • SixSigma
  • 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.

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

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

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

Базовые термины проектного управления

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

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

Событийная цепочка процессов (EPC-диаграмма): диаграмма, отображающая последовательность реализации работ проектов основываясь на доступности и загруженности ресурсов

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

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

Менеджер проекта (руководитель проекта, project manager, PM): Руководитель команды проекта, ответственный за управление проектом (планирование, реализацию и закрытие проекта).

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

Содержание проекта (Scope): Описание работ, которые необходимо выполнить, чтобы получить продукт.

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

«Классическое» или «традиционное» проектное управление: Наиболее широко распространённый метод управления проектами, основанный на так называемом «водопадном» (Waterfall) или каскадном цикле, при котором задача передаётся последовательно по этапам, напоминающим поток.

Далее мы рассмотрим различные подходы к управлению проектами более подробно. Мы начнём с Классического проектного управления и Agile, а затем рассмотрим Scrum, Kanban, 6 сигм и другие.

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

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 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 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

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

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

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

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

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

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

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

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

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

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

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 столпа, на которых держится вся система:

  1. Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
  2. Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
  3. Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
  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 процессов:

  • Начало проекта (Startingupaproject):В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
  • Инициация проекта (Initiationaproject):В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
  • Руководство проектом (Directingaproject): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
  • Контроль стадии (Controllingastage):При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
  • Управление созданием продукта (ManagingProductDelivery):Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
  • Управление границами стадии (Managingastageboundary): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
  • Завершение проекта (Closingaproject):Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

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

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

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

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

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

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

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

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

Цукерберг рекомендует:  Вакансии Мобильное приложение поиска работы
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих
November 15, 2006 Posted by Sergey Nazarenko under Методологии, Статьи