Agile management: Get started building an agile workflow

Agile Project Management понятными словами — Jony Muminov на vc.ru

Кто такой менеджер в IT?

1436 просмотров

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

Что должен знать менеджер?

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

Что такое Agile?

Многие говорят что это гибкая методология для разработки ПО, НО ЭТО НЕ ТАК

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

Причём тут Менеджер?

В наше время бизнес переживает

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

О каких ценностях идёт речь?

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

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

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

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

Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева

Какой подход к разработке у Agile?

• Гибкая методология разработки (Scrum/KanBan/Lean/XP)

• Постоянное формирование требований на основе целевого видения продукта

• Короткие горизонты планирования (1-2 мес.)

• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля

• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку

Но не всё же так круто?

Действительно что нет в этом мире задумок без минусов, и вот некоторые из них:

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

Каковы 12 принципов Agile?

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

• Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. Главное для Agile-команды — удовлетворенность клиентов, поэтому они обязательно представляют результаты своей работы через регулярные промежутки времени, а не заставляют заказчиков ждать финального результата в конце проекта.
• Изменение требований приветствуется даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения конкурентного преимущества заказчика В этом их преимущество перед традиционными командами, которым обычно не так легко управлять изменениями.
• Работающий продукт следует выпускать как можно чаще, с периодичностью от двух недель до двух месяцев Вспомним, что Agile-команды ценят постоянное общение, а не жестко распланированный выпуск обновлений, которые могут слишком далеко отстоять друг от друга по времени, что может оказаться неприемлемым для клиентов. Команды Scrum, которые тоже работают по методологии Agile, разбивают свою работу на периоды от одной до четырех недель, известные, как спринты.
• На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе Сотрудничество — краеугольный камень Agile, причем имеется в виду не только сотрудничество между членами команды, но и сотрудничество с заинтересованными сторонами, разработчиками, клиентами и другими партнерами.
• Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте им условия, обеспечьте поддержку — и полностью им доверьтесьAgile-команды успешны, потому что в них работают только те люди, которые необходимы для проекта. Если участники Agile-команды получат поддержку, возможность работать вместе и инструменты, необходимые для работы, все остальное приложится.
• Непосредственное общение — наиболее практичный и эффективный способ обмена информацией как с самой командой, так и внутри команды. Все мы знаем, что главное в управлении проектами — личное сотрудничество. Этот принцип применим и во времена «новой нормы», при гибридных и удаленных моделях работы. Zoom и Teams — отличная альтернатива телефонным звонкам и электронной почте, а в ключевых точках проекта возможны и личные встречи команд.
• Работающий продукт — основной показатель прогресса. Смысл принципа, который называет работающий продукт основным показателем прогресса, в том, что главная цель команды всегда остается одна — предоставить клиенту как можно более высококачественный результат. Когда клиент доволен, это и есть главный показатель успеха проекта.
• Agile помогает наладить устойчивый процесс разработки. Инвесторы, разработчики и пользователи должны иметь возможность бесконечно поддерживать постоянный ритм Многие команды поначалу показывают бурный прогресс, который не получается сохранить до конца проекта.
• Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проектаAgile не работает по принципу «раз — и готово». Каждый новый проект — это возможность для инноваций, а не для повтора одних и тех же идей.
• Простота как искусство сократить до минимума лишнюю работу крайне необходима Команды Agile не занимаются переусложнением — они просто соблюдают проектные требования и хорошо выполняют свою работу, а затем переходят к следующему проекту.
• Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд Лучшие команды — это те команды, у которых есть лидер, предоставляющий им свободу самовыражения. Микро — менеджмент редко делает команды лучше или продуктивнее, и Agile-команды — отличный пример того, чего можно добиться без микро-менеджмента.
• Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы Непрерывное совершенствование — сама суть Agile, и регулярные проверки эффективности команды в целом могут помочь избавиться от вредных привычек и добиваться большего.

Обучение «Agile Project Management (PMI-ACP)» — курс в компании ScrumTrek

Этот тренинг для вас, если вы:

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

Как проводится онлайн-интенсив:

• Работаем в малых группах по методу Training From The Back Of The Room, чтобы сохранить вовлеченность, эффективность и интерес.
• Игры и симуляции — так же, как на офлайн-тренинге.
• Для сохранения концентрации каждый день обучения состоит из нескольких блоков с перерывами между ними.

Важная информация

1

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

2

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

Программа курса:

• Новые требования к методам управления изменениями. Agile как ответ на современные вызовы.
• Ограничения проекта: новый взгляд на «железный треугольник».
• Что такое Agile-проект?
• Нужен ли моему проекту Agile? (область применимости Agile)
• Делим проект на инкрементальные части.
• Команда Agile-проекта (роли, структура и принципы взаимодействия).
• Разрабатываем процесс для реализации проекта (Scrum, Kanban).
• Запуск Agile проекта (Chartering).
• Разрабатываем Vision и Roadmap Agile-проекта (Agile Project Charter).
• Работаем с требованиями в Agile-проекте (принципы и инструменты).
• Оцениваем Agile-проект и прогнозируем сроки (принципы и инструменты).
• Работаем с рисками в Agile-проектах (принципы и инструменты).
• Бюджетирование и контрактование в Agile-проектах (принципы и инструменты).
• Agile-трансформация организации, внедряем изменения.
• Новые роли проектного менеджера и проектного офиса.
• Agile в PMBoK 7.
• Подготавливаемся к сдаче экзамена PMI-ACP.
• Решение примеров вопросов экзамена PMI-ACP.

Групповые скидки:

• От 2 до 4 участников — скидка 5%.
• От 5 и больше участников — скидка 10%.

В стоимость курса входит:

• Получение сертификата от консорциума ICAgile – Agile Project Management. Прохождение сертификационного экзамена PMI-ACP в стоимость тренинга не входит, оплачивается отдельно в PMI и осуществляется в специальном авторизованном сертификационном центре Pearson VUE.

Оплата курса возможна:

• По счету от юридического лица (выдается акт об оказании услуг).
• Банковской картой (выдается электронный кассовый чек).

Корпоративный формат:

1

Обучение происходит на нашей образовательной онлайн-площадке.

2

Запрос на проведение корпоративного онлайн-интенсива можно направить на [email protected].

Фото и отзывы

Наталья ЗотоваМаксима Телеком

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

Артем РоманчукDostavista

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

Игорь ЗатонскийX5

Отлично, есть теория и примеры из практики.

Анна БлагихЛаборатория Касперского

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

Павел МашковКРОК ИНКОРПОРЕЙТЕД

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

Виктория ОвсянниковаLamoda

Если вы и ваш бизнес планируете эффективно и быстро развиваться в 21 веке, то стоит обратить внимание и внедрить Agile. Курс откроет и покажет новые возможности развития.

Денис ПерсинOpenWay Group

Тренинг был интересным и дал всестороннее представление об Agile. Тренер хорошо ведет обучение и управляет группой. Много визуальных материалов. Интересный интерактив. Я доволен.

Тренер

Артемий Анцупов

Agile Coach и тренер, в прошлом менеджер проектов и методолог. Партнер ScrumTrek c 2018 года. Scrum и Kanban практик. Занимаюсь развитием онлайн-обучения. Энтузиаст Бирюзовых организаций.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Тренер по Agile: эпики
• Тренер по Agile: истории

Agile epic vs. Initiative

90 005

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

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

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

В Atlassian:

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

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

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

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

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

Узнайте, как Twitter объединил проекты и совместную работу с Jira: Читать полностью

 

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

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

 

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

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

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

 

Макс Рекопф

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

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

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

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

Выполнено

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

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

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

Готово к слиянию

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

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

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

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

Оптимизация для гибкого технологического процесса

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

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

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

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

Проблемы масштабирования agile-процесса

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

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