Google Project Management: Professional Certificate, все самое главное из курса для начинающих, часть 5

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

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

1. Основы управления проектами (Foundations of Project Management)

2. Инициация проекта: запуск успешного проекта (Project Initiation: Starting a Successful Project)

3. Планирование проекта: объединяя всё воедино (Project Planning: Putting It All Together)

4. Исполнение проекта: реализация на практике (Project Execution: Running the Project)

5. Agile‑управление проектами (Agile Project Management)

6. Итоговый проект: применение управления проектами в реальном мире (Capstone: Applying Project Management in the Real World)

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

Приятного чтения!

1. Agile‑управление проектами (Agile Project Management)

Severance tv show, продакт менеджер Seth Milchick

Полезные ресурсы:

https://agilemanifesto.org/principles.html

https://hbr.org/1986/01/the-new-new-product-development-game

https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf

https://www.scrumguides.org/scrum-guide.html

https://www.scrum.org/resources/what-is-scrum

https://www.infoq.com/articles/great-scrum-team/

https://www.scrumguides.org/scrum-guide.html#product-backlog

https://asana.com/

https://clickup.com/

https://monday.com/

https://docs.google.com/spreadsheets/d/1rzN_bKNORL4o7IyXDbcmWDk-Rdg11AvXi4_ut6ID0q0/template/preview?resourcekey=0-wzrYz2j_uOOL97KuTlLBeg#gid=2118111924

https://help.clickup.com/hc/en-us/articles/7255526314391-Set-time-estimates

https://monday.com/blog/project-management/estimate-template/

https://docs.google.com/document/d/1Nhmx9OiBgmzglWqnqYdXvj1uQGEaqAJWiRkcRdkCCtg/template/preview#heading=h.gjdgxs

https://www.youtube.com/watch?v=502ILHjX9EE

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2020-04/Penta_April2020-2.pdf

https://www.scrum.org/resources/blog/product-roadmap-first-principles-empower-scrum-teams-align-w-stakeholders

https://docs.google.com/document/d/1fgZ2k-4E11fvEpLQgRec1HxG0YiqOw3fjDc92L8vnyI/template/preview

https://www.prnewswire.com/news-releases/influencer-the-new-science-of-leading-change-207352831.html

https://sourcesofinsight.com/influencer-the-power-to-change-anything/

https://devops.com/how-to-combine-devops-and-agile/

https://www.cmswire.com/information-management/agile-vs-devops-whats-the-difference/#:~:text=Fundamentally%2C DevOps brings together two,the ever-changing consumer needs.&text=-based Shiftleft%2C explained how both Agile and DevOps are managed

https://www.scrum.org/resources/convergence-scrum-and-devops

https://www.pmi.org/disciplined-agile/process/introduction-to-dad

https://less.works/

https://www.atlassian.com/agile/scrum/scrum-of-scrums

https://www.scaledagileframework.com/

https://docs.google.com/document/d/1pxqBWSYs5ulcpE51yXWZmxxeohck0nZ2mshUWAv_D4M/template/preview?resourcekey=0-vbWADp_sFCEyBgitSgiRXw

Waterfall против Agile: ключевые различия и основы Agile

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

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

Итак, термин «Agile» означает гибкость, повторяемость и открытость к изменениям, но что мы подразумеваем под Agile-управлением проектами? Agile-управление проектами — это подход к управлению проектами и командами, основанный на Манифесте Agile. Манифест представляет собой набор из четырёх ценностей и 12 принципов, которые определяют мышление, к которому должны стремиться все Agile-команды.

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

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

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

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

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

Но вот что делает Agile ещё более интересным. Вы всё ещё можете использовать Agile, даже если не планируете работать над проектами по разработке программного обеспечения. Agile был настолько успешным в индустрии программного обеспечения, что его ценности, принципы и фреймворки были применены практически во всех отраслях. Фактически, методы Agile, которые вы собираетесь изучить, также в значительной степени основаны на принципах бережливого производства (Lean manufacturing), которые зародились на автомобильных заводах Toyota в 1930-х годах. Вы также найдёте методы Agile, применяемые в аэрокосмической, медицинской, образовательной, финансовой и многих других отраслях. Agile повсюду.

Agile против Waterfall: требования, документация и результаты

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

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

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

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

Требования

• Waterfall: Требования фиксируются в начале проекта в документе о требованиях к продукту. Изменения управляются через формальный процесс, часто с помощью совета по контролю изменений. Это сделано для защиты от создания того, что клиент не хочет, и минимизации изменений, которые могут привести к расползанию объёма. Такой подход хорошо работает, когда конечный продукт известен и понятен, например, в проектах, основанных на законодательных требованиях. Однако есть риск создания всего продукта, который потом не понравится клиенту.

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

Документация

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

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

Результаты (deliverables)

• Waterfall: Результаты часто не выпускаются до самого конца проекта. Выпуск конечного продукта ощущается как большое событие с крупными анонсами.

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

Ценности и принципы Agile-манифеста

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

Четыре ценности Agile

Манифест Agile-разработки программного обеспечения гласит:

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

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

• Сотрудничество с заказчиком важнее согласования условий контракта.

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

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

12 принципов Agile

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

12 принципов Agile: сердце каждого проекта

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

• «Наш высший приоритет — удовлетворить клиента путём ранней и непрерывной поставки ценного продукта.» Неважно, создаёте ли вы продукт для своей компании или для внешнего клиента, кто-то всегда ждёт его поставки. Если доставка задерживается, клиент, пользователь или организация остаются в ожидании той самой ценности, которую продукт должен принести в их жизнь и работу. Agile подчёркивает: ранняя и частая поставка ценности пользователям создаёт стабильный поток ценности, умножая ваш успех и успех вашего клиента. Это строит доверие и уверенность благодаря постоянной обратной связи и быстрой реализации бизнес-ценности.

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

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

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

• «Стройте проекты вокруг мотивированных людей. Дайте им окружение и поддержку, в которых они нуждаются, и доверяйте им в выполнении работы.» Успешная Agile-команда состоит из мотивированных членов, которые не только доверяют друг другу в выполнении работы, но и пользуются доверием своих спонсоров и руководителей. Команды создают лучшие решения, когда они полномочны и мотивированы на выполнение сложных проектов.

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

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

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

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

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

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

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

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

Когда Agile — лучший выбор

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

Какие ещё отрасли, помимо программного обеспечения, приходят на ум, где постоянно происходят изменения? Например:

• Биотехнологии с постоянно появляющимися вакцинами, методами лечения и технологиями.

• Медиа с бесконечными новыми способами распространения контента.

• Пищевая индустрия с новыми поварами-знаменитостями и последними кулинарными причудами.

• Мода, отрасль, построенная на постоянном следовании меняющимся тенденциям.

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

Концепция VUCA: Понимание меняющегося мира

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

VUCA расшифровывается как:

• Volatility (Изменчивость)

• Uncertainty (Неопределённость)

• Complexity (Сложность)

• Ambiguity (Неоднозначность)

Давайте объясним каждую составляющую и что она может подразумевать в проектах и бизнесе.

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

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

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

4. Неоднозначность (Ambiguity): Относится к возможности неправильного понимания условий и первопричин событий или обстоятельств. Проект, страдающий от неоднозначности, будет испытывать трудности с точным определением причин задержек проекта, что затруднит разработку планов по снижению рисков.

Scrum: Основы методологии гибкого управления проектами

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

Ключевые принципы и термины Scrum:

• Бэклог (Backlog): Центральный элемент, где собираются все идеи, задачи, функции или элементы, над которыми предстоит работать команде. Он постоянно приоритизируется и управляется на протяжении всего проекта.

• Спринт (Sprint): Ограниченный по времени период (от одной до четырех недель, чаще всего две), в течение которого выполняется работа над определенным набором задач из бэклога. Это также называют итерацией.

• Ежедневный Scrum (Daily Scrum), или «Stand-up»: Короткое (15 минут или менее) ежедневное совещание команды в течение Спринта для обсуждения прогресса и выявления препятствий.

Роли в Scrum:

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

• Владелец продукта (Product Owner): Отвечает за максимизацию ценности продукта и работы команды. Он управляет бэклогом и имеет последнее слово в приоритизации задач.

• Команда разработки (Development Team): Несет ответственность за то, как продукт будет реализован.

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

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

Подходящие проекты и команды для Scrum:

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

Другие популярные Agile-методологии: Kanban, XP и Lean

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

Kanban:

• Название происходит от японских слов "Kan" (знак) и "ban" (доска).

• Наиболее известная особенность — Kanban-доска, которая визуально отображает статус работы (к выполнению, в процессе, выполнено), обеспечивая прозрачность.

• Метод ограничивает количество одновременно выполняемой работы (Work-In-Progress limit, WIP-лимит), чтобы команда не брала на себя больше, чем может справиться, тем самым ускоряя выполнение задач. Целью является поток (flow) — максимальная эффективность.

Экстремальное программирование (XP):

• Изначально возникло в сфере разработки программного обеспечения, но применимо и в других областях.

• Цель XP — улучшение качества продукта и способность быстро реагировать на меняющиеся потребности клиентов.

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

• Четыре основные деятельности XP:

  • Проектирование: Упор на простоту, чтобы продукт соответствовал базовым требованиям.

  • Кодирование: Требование к четкому и лаконичному коду/инструкциям, чтобы другие могли легко понять и работать с продуктом.

  • Тестирование: Интенсивное тестирование для выявления и устранения недостатков на ранних этапах.

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

• Другие инновационные практики XP:

  • Парное программирование: Два члена команды работают над одной задачей вместе.

  • Непрерывная интеграция и непрерывный рефакторинг: Частые слияния изменений в общую версию для быстрой обратной связи.

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

  • Написание тестов вместо требований: Тест-план может служить как инструкцией к сборке, так и инструментом для проверки соответствия.

Lean-методология:

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

• Пять принципов Lean:

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

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

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

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

  • Стремиться к совершенству: Постоянно улучшать первые четыре шага процесса.

Гибкость и смешивание методологий

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

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

Причины для смешивания Agile и Waterfall:

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

• Регуляторные требования: Некоторые отрасли требуют традиционных процессов, например, больших документов с требованиями для сертификации.

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

• Особенности команды: Если проектная команда уже привыкла к Scrum, но часть проекта требует традиционных методов.

Примеры смешивания методов:

• Использование парного программирования (из XP) в рамках Спринта Scrum, когда два члена команды работают над одной задачей.

• Использование Kanban-доски для отслеживания прогресса в Scrum-спринте.

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

Модель Spotify: Гибкость в масштабировании Agile-команд

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

Организационная структура модели Spotify:

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

• Отряды (Squads): Самоорганизующиеся, территориально сгруппированные команды, работающие над долгосрочной миссией (например, улучшение юзабилити приложения для Android). Каждый отряд действует как стартап внутри компании, не имеет формального лидера, но имеет Владельца продукта, которые сотрудничают для отслеживания общего прогресса Spotify. У каждой команды также есть доступ к Agile-коучу.

• Племена (Tribes): Объединения отрядов, работающие в определенной области, численностью до 100 человек.

• Главы (Chapters): Небольшие группы людей из разных племен, обладающие схожими навыками и работающие в одной и той же области компетенции.

• Гильдии (Guilds): Самые большие группы, состоящие из людей со всей организации, желающих обмениваться знаниями, инструментами, кодом и практиками.

Вдохновляться, но не копировать:

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

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

Scrum: Основы самого популярного Agile-фреймворка

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

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

Теория Scrum: Три столпа

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

• Итеративный: Процессы проекта повторяются в коротких временных рамках, называемых итерациями или спринтами.

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

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

Эмпиризм и, соответственно, Scrum, основываются на трех ключевых столпах:

1. Прозрачность: Наиболее важные аспекты работы должны быть видны всем, кто отвечает за результат, включая членов команды, спонсоров и даже пользователей. Это способствует доверию, сотрудничеству и уменьшает количество ошибок. Малый размер команд Scrum (3-9 человек) облегчает достижение прозрачности.

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

3. Адаптация: Постоянный поиск способов корректировки проекта, продукта или процессов для минимизации отклонений и проблем. В Scrum изменения приветствуются, что позволяет команде постоянно совершенствоваться на основе полученной информации.

Пять ценностей Scrum

Помимо трех столпов, команды Scrum придерживаются пяти основных ценностей, которые направляют их поведение:

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

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

3. Фокус: Сосредоточенность каждого на необходимой работе в рамках Спринта и на общих целях команды Scrum. Скрам-мастер помогает команде сохранять фокус.

4. Открытость: Готовность команды и заинтересованных сторон быть открытыми относительно всей работы и возникающих проблем. Это способствует обмену опытом и поиску решений.

5. Уважение: Уважение к мнениям, навыкам и независимости коллег. Взаимное уважение способствует эффективной обратной связи и успеху продукта.

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

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

Роли в команде Scrum: Миссия, видение и ключевые функции

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

Миссия и видение продукта:

• Миссия — это короткое, неизменное утверждение, объясняющее, почему команда выполняет ту или иную работу. Например, для проекта Office Green "Virtual Verde" миссией является: "Virtual Verde улучшает здоровье и счастье пользователей, оживляя их домашнее рабочее пространство".

• Видение продукта помогает представить, каким будет результат работы после её завершения. Для "Virtual Verde" видение продукта может быть таким: "Virtual Verde — это живая торговая площадка, которая преображает домашний офис".

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

Три основные роли в Scrum-команде:

Каждая Scrum-команда состоит из трёх определённых ролей, которые работают вместе для достижения целей и реализации миссии и видения:

1. Владелец продукта (Product Owner):

   • Отвечает за "что" — определяет, что команда будет создавать.

   • Максимизирует ценность продукта, выступая "голосом клиента" в команде.

   • Создаёт и приоритизирует Бэклог продукта (список всех функций, требований и задач), обеспечивая его прозрачность.

   • Обеспечивает понимание командой, почему их работа важна.

   • Требуемые качества: Ориентированность на клиента, решительность, отличные коммуникативные навыки, гибкость, оптимизм, доступность и умение работать в команде.

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

2. Команда разработки (Development Team / Developers):

   • Отвечает за "как" — строит продукт.

   • Состоит из 3-9 человек, которые выполняют всю работу по созданию продукта.

   • Является кросс-функциональной, то есть обладает всеми необходимыми навыками для создания продукта или услуги собственными силами (например, разработчики, тестировщики, UX-специалисты).

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

   • Сосредоточена на поставке качественных инкрементов, соответствующих "Определению готовности" (Definition of Done).

   • Ежедневно адаптирует свой план для достижения цели Спринта.

   • Предпочитает совместную работу, часто работая вместе в одном физическом пространстве для улучшения коммуникации и качества, хотя удаленная работа также возможна.

3. Скрам-мастер (Scrum Master):

   • Отвечает за "когда" — помогает команде доставлять ценность пользователям.

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

   • Осуществляет коучинг по практикам Agile и Scrum.

   • Фасилитирует Scrum-события (например, Ежедневный Scrum, Ретроспективы Спринта), следя за их продуктивностью и соблюдением временных рамок.

   • Устраняет препятствия, такие как отсутствие информации или доступа к инструментам.

   • Предотвращает отвлекающие факторы извне команды.

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

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

Взаимодействие ролей:

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

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

Артефакты Scrum: Бэклог продукта, пользовательские истории и Эпосы

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

Бэклог продукта

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

• Живой артефакт: Он постоянно пополняется новыми элементами по мере развития проекта.

• Владелец и корректировка: За Бэклог продукта отвечает Владелец продукта, который постоянно его корректирует.

• Приоритизированный список: Элементы всегда располагаются в порядке приоритета, от самых важных и детализированных сверху до менее определённых внизу.

При работе с Бэклогом продукта рекомендуется учитывать четыре поля для каждого элемента:

1. Описание: Чёткое и детализированное описание элемента, часто написанное с точки зрения клиента.

2. Ценность: Показывает, какую бизнес-ценность элемент принесёт клиентам, команде или пользователям. Способ оценки ценности (например, с помощью символов валюты) определяется командой.

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

4. Порядок: Приоритет элемента в списке (например, по принципу стекового ранжирования — от наивысшего к наименьшему).

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

Пользовательские истории

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

При написании пользовательских историй важно:

• Определить пользователя: Создание персон пользователей (подробных описаний различных типов пользователей) помогает лучше понять их потребности.

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

• Соответствовать критериям INVEST:

  • Independent (Независимая): История может быть начата и завершена сама по себе, без зависимости от других историй.

  • Negotiable (Обсуждаемая): Есть место для переговоров и обсуждений по этому элементу.

  • Valuable (Ценная): Завершение истории приносит ценность.

  • Estimable (Оцениваемая): Команда может оценить трудозатраты на выполнение.

  • Small (Маленькая): История должна быть достаточно маленькой, чтобы поместиться в один Спринт.

  • Testable (Тестируемая): Можно написать тест для проверки выполнения критериев приёмки.

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

Эпосы

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

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

Создание Бэклогов продукта с помощью инструментов управления работой

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

Для менеджера проекта важно освоить различные инструменты управления работой, так как они могут значительно оптимизировать процессы команды и повысить продуктивность. Хотя конкретные инструменты могут отличаться (например, Asana, Jira, Trello), многие из них имеют схожие функции и логику.

Инструменты управления работой и Бэклоги продукта:

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

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

Использование таких инструментов позволяет:

• Централизовать информацию: Все задачи и требования собраны в одном месте, что снижает время на поиск и переключение между приложениями.

• Автоматизировать обновления: Многие инструменты позволяют настроить автоматическое обновление и переприоритизацию элементов Бэклога.

• Улучшить прозрачность: Прогресс и изменения в Бэклоге видны всем членам команды и заинтересованным сторонам.

• Повысить продуктивность: Уменьшение "работы ради работы" позволяет команде сосредоточиться на выполнении задач и создании ценности.

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

Уточнение Бэклога и Оценка Трудозатрат в Scrum

Чтобы Бэклог продукта оставался актуальным и полезным инструментом, команды Scrum проводят процесс, называемый уточнением Бэклога (Backlog refinement). Это постоянная деятельность, в ходе которой команда (Владелец продукта и часть или вся Команда разработки) просматривает Бэклог, чтобы убедиться в его актуальности, правильной приоритизации и готовности элементов к работе.

В процессе уточнения Бэклога команда убеждается, что:

• Состав Бэклога актуален: Нет лишних или недостающих элементов.

• Элементы приоритизированы: Владелец продукта расставил их по важности.

• Высокоприоритетные элементы готовы к доставке: У них есть чёткие критерии приёмки.

• Элементы Бэклога содержат оценки: Примерное понимание объёма работы.

Оценка трудозатрат: Относительная оценка

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

Два наиболее распространённых метода относительной оценки:

Размеры футболок (T-shirt sizes):

• Простой метод для новичков в относительной оценке.

  • Команда выбирает один элемент Бэклога, который считается "средним" по объёму работы.

  • Все остальные элементы сравниваются с этим "средним" и получают размеры (XS, S, M, L, XL, XXL).

  • Этот метод быстр и интуитивно понятен.

Сторителлинг-баллы (Story points):

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

  • Команда выбирает "якорный" элемент и присваивает ему баллы.

  • Для оценки остальных элементов используется последовательность Фибоначчи (0, 1, 1, 2, 3, 5, 8, 13, 21...), где числа расходятся по мере увеличения, отражая растущую неопределённость и риск в больших задачах.

  • Сторителлинг-баллы объединяют в себе оценку трудозатрат и риска. Они позволяют лучше выявить сложные и рискованные части проекта.

Преимущества относительной оценки:

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

• Предотвращение эффекта привязки (anchoring bias): Методы, такие как "Планирование покера", позволяют членам команды сначала дать независимую оценку, прежде чем обсуждать её с группой.

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

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

Техники оценки усилий Agile:

Помимо "Размеров футболок" и "Сторителлинг-баллов", существует множество других техник для оценки усилий в Agile-проектах:

Планирование покера (Planning Poker™): Команда использует колоду карт с числами Фибоначчи. Каждый член команды одновременно выкладывает карту лицом вниз, а затем все открывают их. Обсуждаются сильно отличающиеся оценки.

• Голосование точками (Dot Voting): Члены команды используют цветные стикеры-точки для оценки элементов Бэклога, написанных на карточках.

• Система ведер (The Bucket System): Быстрый метод для больших бэклогов. Элементы распределяются по "ведрам" с предопределёнными уровнями сложности (номера Фибоначчи на карточках).

• Большой/Неопределённый/Малый (Large/Uncertain/Small): Упрощённая версия "Системы ведер" с тремя категориями.

• Метод упорядочивания (Ordering Method): Команда последовательно перемещает элементы вверх или вниз по шкале приоритета.

• Картирование сродства (Affinity Mapping): Элементы группируются по схожим темам, а затем группы приоритизируются.

Лучшие практики оценки:

Независимо от выбранной техники, эффективная оценка включает:

• Задавание Владельцу продукта вопросов для уточнения элементов.

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

• Согласование окончательной оценки и её фиксация в системе.

• Разделение крупных элементов на более мелкие, если это целесообразно.

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

Оценка трудозатрат в инструментах управления работой

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

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

Использование инструментов управления работой для добавления оценок

Многие инструменты управления работой, такие как Asana, ClickUp или Monday.com, позволяют легко интегрировать оценки трудозатрат в ваш Бэклог продукта.

Вот как это можно сделать, используя Asana в качестве примера:

1. Создание нового проекта путём импорта CSV-файла:

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

   • На дашборде Asana нажмите кнопку "Создать" (Create), затем выберите "Импортировать таблицу" (Import spreadsheet).

   • Назовите проект, например, "Виртуальный Верде Бэклог" (Virtual Verde Backlog).

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

2. Добавление оценок трудозатрат:

   • При импорте CSV-файла Asana автоматически генерирует пользовательские поля для вашего Бэклога, такие как "Эпос" (Epic), "Ценность" (Value) и "Оценка (баллы истории)" (Estimate (Story Points)).

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

     • Например: "Варианты с низким уровнем обслуживания: 8", "Советы по уходу за растениями: 8", "Инструменты для ухода за растениями: 13", "Напоминания о поливе: 5", "Экспертная помощь и советы: 8", "Политика возврата: 5".

3. Сортировка пользовательских историй:

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

   • Например, вы можете отсортировать проект по полю "Ценность" для лучшего понимания приоритетов.

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

   • Также вы можете переключиться на "Вид доски" (Board view) для работы с Бэклогом в стиле Канбан, а затем также сохранить этот вид по умолчанию.

Ключевые преимущества использования таких инструментов

Использование инструментов управления работой для Бэклога даёт ряд значительных преимуществ:

• Быстрое превращение планов в действия: Вы можете оперативно назначать ответственных и сроки выполнения для каждой пользовательской истории, что обеспечивает ясность в обязанностях и сроках.

• Согласованность команды: Публикация еженедельных отчётов о статусе, highlighting achievements, progress, and blockers помогает держать всех в курсе.

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

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

Спринты: Обзор и Управление с помощью Инструментов

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

Обзор Спринта

Спринты — это "сердцебиение" Scrum, где идеи превращаются в ценность.

• Это события фиксированной длительности (не более месяца) для обеспечения последовательности. Новый Спринт начинается сразу после завершения предыдущего.

• Вся работа, необходимая для достижения цели продукта, включая Планирование Спринта, Ежедневные Скрамы, Обзор Спринта и Ретроспективу Спринта, происходит внутри Спринтов.

• Во время Спринта:

  • Не вносятся изменения, которые могут поставить под угрозу Цель Спринта.

  • Качество не снижается.

  • Бэклог продукта уточняется по мере необходимости.

  • Объём работ может быть уточнён и пересмотрен совместно с Владельцем продукта по мере получения новой информации.

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

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

• Отмена Спринта возможна, если Цель Спринта устарела. Только Владелец продукта имеет право отменить Спринт.

Планирование Спринта

Это первое событие в рамках Спринта, на котором вся команда Scrum собирается, чтобы:

• Определить доступную ёмкость команды (время и ресурсы).

• Выбрать элементы из Бэклога продукта, которые будут выполнены в течение Спринта.

• Сформировать Бэклог Спринта — подмножество элементов из Бэклога продукта, которые команда планирует завершить в текущем Спринте.

• Сформулировать Цель Спринта — общую задачу, которую команда стремится достичь в течение Спринта.

Пример использования Asana:

1. Добавление пользовательского поля для Спринтов:

   • В Asana можно добавить пользовательское поле "Спринт" (Sprint), чтобы легко отслеживать, к какому Спринту назначена каждая задача.

   • В поле "Спринт" можно добавить варианты, такие как "Текущий Спринт" (Current Sprint) и "Следующий Спринт" (Next Sprint).

2. Назначение элементов Бэклогу Спринта:

   • В представлении списка (List view) Asana удобно назначать элементы Бэклогу Спринта, выбирая соответствующий Спринт в выпадающем списке столбца "Спринт".

   • Также можно добавить сроки выполнения (Due date) для элементов "Текущего Спринта".

3. Дополнительные возможности:

   • Автоматизация рутинных задач с помощью правил (Rules).

   • Визуализация работы команды с помощью представления "Хронология" (Timeline).

   • Создание настраиваемых шаблонов (Custom template) для быстрого запуска новых Спринтов.

Ежедневный Скрам (Daily Scrum)

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

1. Что я сделал вчера, что помогло команде разработки достичь Цели Спринта?

2. Что я буду делать сегодня, чтобы помочь команде разработки достичь Цели Спринта?

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

Обзор Спринта (Sprint Review)

Это встреча, на которой команда демонстрирует результаты своей работы заинтересованным сторонам. В ходе Обзора Спринта:

• Команда разработки демонстрирует работающий продукт.

• Владелец продукта определяет, какие аспекты продукта завершены, а какие нет.

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

• Команда получает обратную связь о проделанной работе.

В результате Обзора Спринта создаётся Инкремент продукта (Product Increment) — готовая к выпуску версия продукта, включающая в себя все элементы, которые соответствуют Определению готовности (Definition of Done).

Ретроспектива Спринта (Sprint Retrospective)

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

• Что работало хорошо.

• Что можно улучшить.

• Какие изменения следует внести в процессы, инструменты или взаимодействие в команде.

Ретроспектива Спринта — важный инструмент для постоянного совершенствования команды и повышения её эффективности.

Мониторинг Прогресса в Scrum: Burndown-диаграммы, Скорость и Инструменты

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

Burndown-диаграммы

Burndown-диаграмма — это визуальный инструмент, который показывает объём оставшейся работы в Спринте или проекте по отношению ко времени. Её цель — держать команду в курсе того, насколько успешно она движется к своим целям.

• Как это работает: На диаграмме по оси Y откладываются оставшиеся стори-поинты (или сопоставленные числовые значения для размеров футболок), а по оси X — время (дни Спринта). Идеальная линия показывает равномерное снижение работы, а фактическая линия отражает реальный прогресс.

• Использование: Скрам-мастер ежедневно просматривает burndown-диаграмму, чтобы понять, достигнет ли команда своих целей. Если фактический прогресс значительно отстаёт от идеального, это сигнал для обсуждения и поиска путей устранения препятствий.

• Пример: Если Спринт длится 20 рабочих дней, а общий объём работы составляет 200 поинтов, идеальный burndown составляет 10 поинтов в день. Отслеживая фактическое сжигание поинтов, команда может видеть, опережает ли она или отстаёт от графика.

Скорость (Velocity)

Скорость — это мера того, сколько стори-поинтов команда в среднем "сжигает" (завершает) за один Спринт. Это исторический показатель, основанный на предыдущих Спринтах.

• Расчёт: Скорость обычно рассчитывается как среднее количество стори-поинтов, выполненных за последние 3-5 Спринтов.

• Использование: При планировании Спринта команда использует свою среднюю скорость, чтобы определить, сколько элементов они могут безопасно добавить в Бэклог Спринта.

• Важные замечания:

  • Нет "хорошей" или "плохой" скорости: Скорость — это просто исторический показатель производительности конкретной команды.

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

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

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

Доски Канбан/Scrum

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

• Три основные функции:

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

  2. Ограничения на незавершённую работу (WIP-лимиты): Доски помогают визуализировать и применять ограничения на количество задач, над которыми команда активно работает в любой момент времени, что способствует фокусировке и повышает эффективность.

  3. Поток работы: Доска позволяет команде "перемещать" элементы из одного этапа в другой ("К выполнению" -> "В работе" -> "Готово"), обеспечивая наглядное представление о движении работы через процесс выполнения.

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

Инструменты для управления Scrum

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

• Инструменты управления расписанием и работой (Work Management Tools):

  • Jira (by Atlassian): Очень популярный инструмент для Agile-команд, поддерживающий все аспекты управления командой, Бэклогом, Спринтами, скоростью и Burndown-диаграммами.

  • Asana: Отлично подходит для планирования Спринтов, управления Бэклогом, назначения задач, автоматизации рабочих процессов, отслеживания прогресса и коммуникации.

  • Trello: Простое и интуитивно понятное решение, особенно хорошо для Канбан-досок, подходит для небольших команд или личных проектов.

  • Другие аналоги: ClickUp, Monday.com.

  • Некоторые команды используют специализированные возможности электронных таблиц (Excel, Google Sheets) для создания собственных Agile-инструментов.

• Инструменты для документации и обработки текстов:

  • Google Docs, Microsoft Word: Для создания подробной документации и захвата ключевой информации по проекту. Многие из них также поддерживают совместную работу.

  • Электронные таблицы (Google Sheets, Microsoft Excel): Для сбора данных о Бэклоге, элементах Бэклога и другой проектной информации.

• Инструменты для презентаций:

  • Google Slides, Microsoft PowerPoint: Для представления информации команде и заинтересованным сторонам.

• Инструменты для сотрудничества и коммуникации:

  • Видеоконференцсвязь: Google Meet, Zoom, Microsoft Teams.

  • Командные и индивидуальные онлайн-чаты: Slack, Microsoft Teams, Google Chat.

  • Электронная почта: Для формальной коммуникации и обмена важной информацией.

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

Доставка Ценности в Agile и Scrum

В рамках Agile и Scrum основной акцент делается на ценностно-ориентированную доставку (value-driven delivery), что означает постоянное стремление команды к созданию и предоставлению продукта, который приносит максимальную ценность для пользователей и клиентов.

Что такое Ценность?

Ценность может иметь разные значения для разных клиентов и проектов. Она может проявляться в:

• Финансовых выгодах: Увеличение прибыли, снижение затрат.

• Росте и вовлеченности пользователей: Привлечение новых клиентов, повышение их удовлетворенности.

• Соответствии требованиям: Соблюдение стандартов, норм и правил.

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

Три Столпа Ценностно-Ориентированной Доставки

Чтобы обеспечить ценностно-ориентированную доставку, команда должна придерживаться следующих принципов:

1. Создавать правильную вещь (Build the right thing):

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

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

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

2. Создавать вещь правильно (Build the thing right):

   • Это означает, что команда должна работать только над запрошенными и утверждёнными функциями.

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

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

3. Правильно управлять (Run it right):

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

   • Важные вопросы: Как пользователи будут получать поддержку? Как продукт будет продолжать приносить ценность после первоначальной доставки? Как новые функции будут доходить до существующих пользователей?

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

Пример: Команда Virtual Verde

• Создавать правильную вещь: Опросы клиентов для выявления предпочтений по видам растений и стилям домашнего офиса.

• Создавать вещь правильно: Работа с надёжными поставщиками растений и дизайнерами для обеспечения качества и соответствия запросам клиентов.

• Правильно управлять: Внедрение опросов удовлетворённости клиентов после доставки, предложение дополнительных услуг (поливалки, автоматические системы ухода, советы по садоводству) для поддержания долгосрочной ценности и лояльности.

Дорожная Карта Ценности (Value Roadmap)

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

Дорожная карта ценности состоит из трёх ключевых компонентов:

1. Видение продукта (Product Vision):

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

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

2. Дорожная карта продукта (Product Roadmap):

   • Это высокоуровневый план, показывающий ожидаемые требования к продукту и примерный график достижения ключевых вех, часто связанных с выпусками (релизами) продукта.

   • За её создание и поддержание отвечает Владелец продукта.

3. Планы релизов (Release Plans):

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

   • Обычно разрабатываются совместно Владельцем продукта и Менеджером проекта/Скрам-мастером, учитывая ёмкость и скорость команды.

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

Преимущества Дорожных Карт Продукта

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

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

• Понимание объёма работы: Дают примерное представление об объёме работы, необходимой для достижения результатов.

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

Изменения в Планах

Agile признаёт, что изменения неизбежны. Процесс внесения изменений в план включает три этапа:

1. Выявление необходимого изменения: Может касаться объёма (что), времени (когда) или затрат/ресурсов (как). Источниками могут быть обратная связь от клиентов, ретроспективы Спринтов или изменения в зависимостях.

2. Принятие решения об изменении: Определяется "принимающий решение" (обычно Владелец продукта или старший стейкхолдер), собираются данные, обсуждаются преимущества и затраты, и решение документируется.

3. Внедрение изменения: Изменение документируется, обновляются все затронутые артефакты (дорожные карты, Бэклог продукта, планы персонала) с указанием версий или дат, информация доводится до всех заинтересованных сторон, и изменения отслеживаются.

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

Роль Проектного Менеджера в Agile-Трансформации

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

Понимание Организационной Культуры и Управления Изменениями

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

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

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

Как Внедрять Agile/Scrum в Организацию

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

1. Создание чувства причастности и срочности:

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

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

     • Что мешает нам предоставить лучший продукт клиентам?

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

     • Как мы можем помочь нашим командам стать более продуктивными?

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

Модель Изменений "Влиятельный человек" (The Influencer Change Framework)

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

• Измеряемые результаты: Чётко определите, что вы хотите достичь, почему и когда. Цели должны быть SMART (конкретные, измеримые, достижимые, релевантные, ограниченные по времени).

• Жизненно важные поведенческие проявления (Vital behaviors): Определите ключевые действия, которые люди должны предпринять в решающие моменты для осуществления изменений. Например, если разработчик хочет увеличить вовлеченность Владельца Продукта, он отправляет ему макет новой функции для обратной связи.

• Шесть источников влияния: Используйте комбинацию этих источников для повышения шансов на успех изменений:

  1. Личная мотивация: Внутреннее желание индивида принять новое поведение (например, Владелец Продукта вовремя даёт качественную обратную связь).

  2. Личная способность: Наличие у индивида необходимых знаний и навыков для выполнения нового поведения (например, разработчик умеет использовать инструменты для демонстраций).

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

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

  5. Структурная мотивация: Награды или стимулы за новое поведение (например, подарочная карта за кофе для команды, которую Владелец Продукта вручает после каждого Спринта).

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

Роль Проектного Менеджера как Agile-Коуча

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

• Управление vs. Коучинг:

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

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

• Три шага в роли коуча:

  1. Разрабатывайте "игры" вместе с командой: План работы (как команда проводит Обзор Спринта, как работает ежедневно, как публикует планы) должен быть создан совместно с командой. Все решения должны приниматься с её участием.

  2. Предоставляйте обратную связь: Давайте обратную связь своевременно и ежедневно, как "тренер с боковой линии". Анализируйте общую картину, чтобы найти закономерности для улучшения и определить успешные практики для повторения. Обратная связь должна быть не только о проблемах, но и об успехах.

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

Распространённые Проблемы и Способы Их Решения

Внедрение Agile и управление Agile-командами сопряжено с типичными вызовами:

1. Проблемы с доставкой ценности:

   • Признаки: Пропуски сроков, медленное выполнение задач, выгорание команды, слишком много незавершённых задач (WIP-work in progress).

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

2. Проблемы с бизнес-сотрудничеством:

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

   • Решения: Увеличьте количество демонстраций для получения постоянной обратной связи, рассмотрите Проектные Спринты по дизайну решений (Solution Design Sprints) с участием всех сторон, вводите изменения в Бэклог только между Спринтами.

3. Проблемы с динамикой команды и культурой:

   • Признаки: Низкий моральный дух, частые конфликты, неразрешённые проблемы, а также (парадоксально) отсутствие конфликтов (что может указывать на небезопасную среду).

   • Решения: Проведите мозговые штурмы о том, как лучше работать вместе, измените рабочие процессы (например, парное программирование, изменение формата встреч), проведите совместные тренинги, используйте техники ретроспектив (например, "Шесть шляп мышления").

4. Нестабильная дорожная карта продукта:

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

   • Решения: Заранее договоритесь о том, как обрабатывать новые возможности, проводите регулярные обзоры дорожной карты со всей командой (не реже одного раза в квартал), способствуйте обмену знаниями между Владельцем Продукта и командой разработки.

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

Эволюция Agile и Ваша Роль в Будущем Управлении Проектами

Agile, появившись в 2001 году, быстро набрал популярность, и сегодня большинство организаций применяют продукто-ориентированную модель, часто с гибридными методологиями. Это подчёркивает важность умения сочетать различные подходы в управлении проектами. Растущая популярность Agile обусловлена необходимостью адаптироваться к "VUCA-миру" (изменчивость, неопределённость, сложность, неоднозначность).

Развитие Agile-Фреймворков

Хотя философия Agile-Манифеста осталась практически неизменной, фреймворки, вдохновленные им, продолжают эволюционировать:

1. DevOps:

   • Определение: Организационное и культурное движение, объединяющее разработку программного обеспечения (Dev) и ИТ-операции (Ops).

   • Цель: Увеличить скорость поставки ПО, повысить надёжность сервисов и создать общее владение среди заинтересованных сторон.

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

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

2. Бизнес-гибкость (Business Agility):

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

   • Масштаб: Охватывает переосмысление финансового планирования, структур управления и отчётности, практики найма и работы с персоналом.

   • Фреймворки для масштабирования: В крупных организациях используются фреймворки, такие как Scrum of Scrums и Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD) и Spotify Model.

   • SAFe (Scaled Agile Framework):

     • Самый популярный фреймворк для масштабирования Lean-Agile.

     • Основан на Kanban, Scrum, Extreme Programming (XP), DevOps, Design Thinking.

     • Основная цель: доставка ценности ("экономический взгляд").

     • Организует работу в "Потоки Ценности Agile Release Trains" (ARTs).

     • Ценности SAFe: Выравнивание, Встроенное качество, Прозрачность, Выполнение программ, Лидерство.

   • Scrum of Scrums:

     • Техника интеграции работы нескольких небольших Scrum-команд, работающих над одним проектом.

     • Включает регулярные встречи (раз в неделю, два раза в неделю или ежедневно), фокусируясь на вопросах: "Что команда сделала вчера? Какие проблемы возникли? Чего команда хочет достичь до следующей встречи? Есть ли блокировки?"

     • Включает Скрам-мастера или "амбассадора" от каждой команды, участвующего в Scrum of Scrums, и Мастера Scrum of Scrums, который фокусируется на общем процессе.

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

   • LeSS (Large-Scale Scrum):

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

     • Основан на 10 принципах (LeSS — это Scrum, Эмпирический контроль процесса, Прозрачность, Больше с меньшим, Фокус на целом продукте, Ориентированность на клиента, Постоянное совершенствование к совершенству, Системное мышление, Бережливое мышление, Теория очередей).

     • Предлагает два фреймворка: Basic LeSS (до 50 человек) и LeSS Huge (50–6000+ человек).

   • DAD (Disciplined Agile Delivery):

     • Гибридный подход, сочетающий стратегии из различных Agile-фреймворков (Kanban, LeSS, Lean Development, Extreme Programming, Agile Modeling).

     • Помогает принимать решения, связанные с процессами, которые не охватываются другими фреймворками.

     • Организован в четыре уровня: Основы, Disciplined DevOps, Потоки ценности, Disciplined Agile Enterprise.

   • Spotify Model:

     • Не является полноценным Agile-фреймворком, а описывает, как Spotify масштабировала Agile.

     • Акцент на культуре, автономии команды, коммуникации, подотчетности и качестве.

     • Ключевые компоненты: Отряды (Squads - автономные команды), Племена (Tribes - несколько Отрядов, работающих над одной областью), Главы (Chapters - специалисты одной области), Гильдии (Guilds - сообщества по интересам).

     • Важность заключается в адаптации практик к организационной культуре.

   • Лучшие практики масштабирования Agile:

     • Рассматривайте масштабируемые модели как общие фреймворки, а не инструкции.

     • Сочетайте элементы из разных фреймворков, сохраняя принципы Agile-Манифеста.

     • Не пытайтесь масштабироваться без предварительного опыта работы с Agile.

     • Не масштабируйтесь, если это не необходимо: чем больше команда, тем сложнее проект.

Применение Agile за Пределами Технологий

Agile активно внедряется во многих отраслях, помимо программного обеспечения:

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

• Строительство: Используется для борьбы с задержками и перерасходами бюджета, адаптируя принципы Agile-Манифеста к строительным терминам.

• Личная жизнь: Методологии Agile (например, Канбан-доски) можно применять для планирования переездов, уборки гаража, организации мероприятий.

Ваша Роль в Будущем Agile

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

Поиск Работы в Agile-Управлении Проектами

• Названия должностей: Agile Project Manager, Scrum Master, IT Agile Project Manager, DevOps Project Manager.

• Что ищут работодатели:

  • Понимание Agile: Кандидат должен знать, что Agile — это не только Scrum, Спринты и Daily Standups, но и фундаментальные ценности: сотрудничество с клиентами, доставка ценности, самоорганизующиеся команды.

  • Гибкость: Понимание, что Waterfall не всегда является "худшим" решением, и что все проекты могут извлечь выгоду из разных подходов (например, чёткие требования, управление рисками в Waterfall).

  • Применимость Agile: Понимание, когда следует использовать Agile-подход или фреймворк для решения конкретных проблем проекта.

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

• Вопросы, которые стоит задать на собеседовании:

  • Насколько руководство поддерживает сочетание различных подходов в управлении проектами?

  • Что мне нужно знать о культуре здесь?

  • Как часто я буду получать информацию о потребностях наших пользователей или клиентов?

  • Как будет выглядеть мой типичный рабочий день на этой должности?

Внедрение Agile в Вашу Текущую Команду

Если вы хотите привнести Agile в свою текущую команду, начните с малого и действуйте стратегически:

1. Начните с малого: Внедряйте Agile-практики по частям (например, Канбан-доска для одного рабочего потока, ретроспектива после важной контрольной точки).

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

3. Будьте стратегичны: Внедряйте новые методы работы, которые напрямую решают текущие проблемы команды (например, относительная оценка для проблем с прогнозированием, Владелец Продукта для проблем с приоритезацией).

4. Найдите союзников: Ищите сторонников Agile в вашей организации или профессиональной сети. Они могут дать совет и поддержку в трудные моменты.

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

На этом пятый модуль закончен, остался последний шестой!