Топ-12 курсов по управлению на agile: scrum, kanban, lean

Гибкий рой: как спроектировать разделяемую работу для команд разработки ПО

Из песочницы

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

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

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

Опыт подготовки к сертификации Professional Scrum Master II (Scrum.org)

Привет всем, хотел рассказать о материалах при подготовке к сертификации PSM II от Scrum.org. Буду очень рад, если поделитесь своим опытом тоже 🙂

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

Подготовка к PSM II

• PSPO open — потому что там бывают вопросы, чтоб вы понимали как коучить PO и как идёт работа с ценностью. (кстати говоря, если вы дошли до PSM II, вы вполне можете сдать PSPO не мучаясь, что я и сделал).
• PSM — потому что это должно отскакивать на зубок. Ценности, роли, события, артефакты.
• PAL-E — чтобы через призму коучинга понимать менеджмент, и некоторые метрики, взрослость компании.
• PSK open — чтобы понимать основы работы с потоком.
• Nexus open — базовые основы пусть не самого популярного, но официального scrum.org решения для масштабирования.

Какие-то другие тесты надо проходить осторожно. В интернете довольно много подготовительных тестов: некоторые из них несколько PMBoK уклона, что норм для PMI-ACP, но другие прям адово извращают саму суть скрама, вводят какие-то новые роли, занимаются всяческим саботажем того, что вы практикуете к моменту подготовки к PSM II — берегите себя

Некоторые элементы равнее, чем другие.

Ниже представлен упрощенный вид организационных элементов одного из моих клиентов.

Мы обнаружили, что некоторые организационные элементы требуются чаще, чем другие для разработки функциональности. Чем чаще требуется конкретный элемент, тем сильнее зависимость. Мы визуализировали силу зависимостей с помощью тепловой карты (heat map) – см. рисунок анонимного упрощенного примера ниже.

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

Элементы, которые “нагреваются” больше всего, указывают на силу зависимости – это горячие точки

Обратите внимание, что элемент WEB необходим в 28% времени для разработки функциональности продукта, APP– в 20% времени, в то время как для LEGAL требуется всего 7%

ПРИМЕЧАНИЕ. Старайтесь не уделять слишком много внимания процентам, это не точная наука, а скорее руководство, которое поможет вам двигаться вперед. Помимо процентов, я также успешно использовал различные шкалы для оценки силы зависимостей, таких как: Редко, Сейчас и Затем, Частота.

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

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

Методология как конструктор: инструкция по сборке

Из современного конструктора LEGO можно собрать только одну модель игрушки, например, самолет. Кастомизировать? Можете поменять местами кресла пилотов — вот и вся кастомизация. Лет 30 назад из конструктора можно было собрать примерно все, от самолета до грузовика, при том же количестве деталей как и в современных. Создатели большинства современных методологий в детстве играли в старое Лего. Те, кто сейчас пользуется методологиями — играли уже в современный. Разница в инженерных практиках огромна.
Под катом Филипп Дельгядо (dph) расскажет об инженерном подходе к формированию методологии. Все проекты и команды разные, а лидеры — неповторимы. Подогнать одну методологию под всех не получится — таких просто нет. Придется брать конструктор и строить из него что-то свое, уникальное. В расшифровке одного из лучших докладов TeamLead Conf не будет секретных тайн шаолиньских монахов — только банальности, проверенные опытом

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

За свою карьеру он попробовал все — от Visual Basic до хардкорного SQL, разрабатывал крупнейший в России букмекерский движок и Яндекс.Деньги, а сейчас работает над нагруженными проектами на Java. Регулярно делает доклады на разных конференциях, в том числе и на HighLoad++.

Scrumboard

Часто демонстрируйте результат при помощи Scrum

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

Управляйте командами на общей доске задач

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

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

Работа короткими циклами

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

Чтобы подобного избежать, применяется так называемый итеративно-инкрементальный подход, когда:

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

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

Scrum

1) Scrum Guide — краткое и ёмкое описание Scrum.

2) Книга Scrum. Революционный метод управления проектами — очень популярна, от автора методологии, по книге прослеживается история создания методики.

3) Книга Scrum. Гибкая разработка ПО. 

Kanban

1) Книга Канбан. Альтернативный путь в Agile. 

2) Настольная игра GetKanban, русифицированную версию которой вы можете приобрести у нас (напишите на info@onagile.ru)

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

Как менеджеру превратиться в Agile-коуча/Scrum-мастера:

1) Collaboration Explained: Facilitation Skills for Software Project Leaders

2) Коучинг agile-команд

3) Тренинг Advanced ScrumMaster & Agile Coach, где мы обучаем искусству выращивания самоорганизованных команд.

Как проводить ретроспективу:

1) Замечательная книга, которая объясняет, как проводить ретроспективы, простым понятным языком. Agile ретроспектива. Как превратить хорошую команду в великую. Она же в оригинале: Esther Derby and Diana Larsen, «Agile Retrospectives: Making Good Teams Great».

2) Онлайн каталог активностей для ретроспектив. Основан на методике описанной в книге (1). 

3) Наш однодневный тренинг по этой теме: Искусство проведения ретроспектив

Для программистов:

1) Программистам рекомендую ознакомиться с книгой «Быстрая разработка программ»: она уже не издаётся, электронную версию можно найти без труда. Вся книга про то, как проектировать и писать код так, чтобы потом было легко его изменять.

2) Классика: Рефакторинг. Улучшение существующего кода. Вообще я рекомендую исключительно все книги Мартина Фаулера. Они все отличные, дают правильный mindset.

3) Refactoring in Large Software Projects: Performing Complex Restructurings Successfully.

Для Product Owner’ов:

Как придумывать именно то, что нужно людям:

1) The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses.

Она же на русском: Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели.

Это вводная книга, больше идеологическая, чем методологическая. Если не читали — читать обязательно.

2) Running Lean: Iterate from Plan A to a Plan That Works.

Это уже по сути методичка. Содержит конкретные понятные шаги что нужно делать. Имеет смысл читать только после прочтения первой книги.

3) Lean Analytics: Use Data to Build a Better Startup Faster. Продолжение первых двух книг.

4) Наш тренинг Agile Product Management.

Роль Product Owner в Agile процессах:

Книга: Пользовательские истории. Гибкая разработка программного обеспечения

Для HR и TOP менеджмента:

1) Книга Открывая организации будущего. Очень полезна для понимания сути Agile-организаций. Много примеров, в том числе не из IT-области.

2) Книга Сердце компании, где рассказывается, как выстраивать работу команды ТОП-менеджеров.

Масштабирование Agile:

1) NEXUS фреймворк.

2) Посмотрите 7-минутный ролик про Scaled Agile Framework (SAFe). Для более глубокого погружения в SAFe обращайтесь к первоисточнику.

3) Интересный кейс масштабирования Agile, не связанный с SAFe.

Веселее. Я серьёзно

В конце есть краткое содержание, если что.
Я много лет занимаюсь эффективностью работы программистов. Испробовал кучу методов, и вычитанных из книг, и выдуманных, составил несколько кейсов и написал тысячи строк кода, чтобы всё это автоматизировать. И всё вроде ничего, но чего-то всё время в моем уравнении не хватало.
Я не мог понять диких скачков этой самой эффективности, в первую очередь у себя самого. Я веду учет своей эффективности на протяжении нескольких лет, в единой системе координат, и все время наблюдаю просто жуткие перепады. Не, ну ладно там скачки при смене места работы, должности, языка программирования – адаптация, время на изучение и т.д. Но почему эффективность скачет при неизменном, казалось бы, контексте?
Поначалу думал, что дело во мне. Ну, такой вот я дурак, не могу стабильно работать. Потом стали бросаться в глаза скачки в работе команды, которой руковожу – опять же, дикие, в 2-3 раза. Не говоря уже о перепадах эффективности отдельных программистов.
Вот вроде всё на месте, без особых изменений. Методы работы не меняются, квалификация только растет, задачи однородные, и по сложности, и по объему. Но вот скачет эффективность и всё.
Потом привел к одной системе координат эффективность разных команд, с которыми работал, и опять вижу существенную разницу – причем, и в абсолютных значениях, и в стабильности. Одни команды всё время тупо росли, другие всё время скакали, по бешеной синусоиде.
Ответ пришел случайно. Всё дело в настроении.

Гибкие методологии: взгляд со стороны бизнеса (часть 1)

Из песочницы

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

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

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

«Смерть Бога» или крах общепризнанных законов построения ИТ-команд и создания ИТ-систем в 21 веке

Основная идея заключается в отказе от унаследованных моделей поведения и способов восприятия реальности, которые являются основой, текстуальным, культурным составом нашего «Я». В философии формирование данной концепции заняло тысячи лет, в мире информационных технологий хватило пятидесяти.
В недалёком прошлом многие процессы были ручные, а пытливые умы их упорядочивали и автоматизировали. Для этого разрабатывались методики и средства, формулировались законы, были написаны сотни книг. Эти методы и практики были достаточно эффективны и приносили свои плоды. Но уже в начале 21 века человечество пришло к тому, что большинство процессов уже автоматизированы, а в ближайшем будущем можно будет сказать, что 100% процессов будут обслуживаться системами, поэтому задача создания инноваций и новых систем усложняется. Необходимо улучшать и упорядочивать уже существующие и “стройные” системы и процессы, и это иногда кардинально меняет подходы и практики для достижения результата, а именно повышения их скорости, качества и эффективности.

Практика применения Agile в подборе и развитии персонала

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

О чем важно помнить при работе над HR-проектами:

Работа на клиента

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

Эксперименты вместо долгого планирования

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

Проверка гипотез и масштабирование положительного опыта

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

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

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

Однако и положительный опыт не означает, что можно «зацементировать» HR-продукт: со временем условия внешней среды будут меняться, и потребуются доработки

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

А также уделять внимание обучению сотрудников и руководителей. 

Прозрачная работа

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

Пусть у команд будут доски со столбцами «Бэклог», «Очередь», «В работе», «Готово» и стикеры с задачами, работа спринтами по 1-2 недели с обязательной ретроспективой в конце и короткими ежедневными стендапами. Это поможет увидеть реальный объем задач и скорость их выполнения, нагрузку на каждого сотрудника, слабые места процесса, которые тормозят реализацию проектов.

Помощь вместо руководства

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

Обратная связь и мотивация

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

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

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

Книга «Agile для всех»

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

Деньги решают. «У нас три разработчика, но мы не умеем работать»

Нам пишут:«Хм, а дайте плиз совет.

Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.

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

Есть ли способы как-то улучшить ситуацию?»

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

III Анализ явления гибкие методологии

1. Определения Гибких методологий

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

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

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

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

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

Подобные приемы скорее всего позаимствованы из более ранних методик. Например, это практикует RUP.

2. Разберем основные идеи Agile Manifesto

1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.

Пункт 1Пункт 2Пункт 3Пункт 4.

3. Обсудим принципы Agile Manifesto

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

Манифесты и карго-культы

За пять лет в коммерческой разработке у меня накопился ряд претензий к манифестам. И я решил, что будет забавно сделать манифест на эту тему. Представляю вам:

Манифест про манифесты

• В манифестах пишут очевидные вещи. Это одна из них.
• Предыдущий пункт — шутка про рекурсию.
• Прежде чем пользоваться советом из чужого манифеста, найди доказательства, что совет работает.
• Это касается и предыдущего пункта.
• Если в манифесте написано что-то правильное, это не означает что все пункты правильны.
• Если вы нашли в манифесте ошибку — он бесполезен.
• Предыдущий пункт — пример ошибки.
• Манифесты склонны становиться карго-культом.
• Добавьте по 1 очку культиста, за каждый непонятный вам пункт. Включая предыдущий и этот.
• Этот манифест подписали: Боб Мартин, Линус Товальдс и Дональд Кнут.
• Конечно, нет. Но если бы от этого манифест стал для вас более ценным, добавьте себе еще 2 очка культиста.
• Добавьте еще 5 очков.
• Если вы склонны объяснять вещи с конца и вас злит, что они не очевидны другим.
• Если вы не вели хотя-бы приблизительный подсчет очков, еще 3 очка штрафа.
• Посчитайте очки и сделайте выводы.

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

Дженнифер Грин, Эндрю Стеллман. Постигая Agile

Эта книга рассказывает о самых популярных agile-подходах – Scrum, XP (экстремальное программирование), Lean (бережливое программирование) и Канбан.

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

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

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

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

Я вернулась из NYC две недели назад с конференции Business Agility Conference, сейчас заканчивается мой двухнедельный карантин — есть время поделиться наблюдениями, как всё происходило в США и как у нас. А заодно, что стоит делать и чего не стоит с точки зрения Agile. Даже в случае пандемии такой инструмент может помочь — упорядочить мысли и действия. Чтобы не метаться бессмысленно, как курица с гречкой вместо головы — что в жизни, что в бизнесе.

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

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

Мне «повезло» увидеть, как начался коронавирус в США — и только я вернулась в Россию, а здесь уже было продолжение. И могу поделиться, в чём разница.

Начало истории: я выступала на конференции в Нью-Йорке, на Business Agility Conference. Это крупнейшая конференция по Agile — проходила она 11-12 марта. Я была единственной русской. И вообще единственным иностранным спикером на сцене.

Факультет «Проджект-менеджмента» от GeekBrains

Длительность	12 месяцев
Уровень	С нуля
Для кого подходит	● ачинающим проджектам и продактам; ● IT-специалисты; ● руководители команд и отделов.
Формат	Видеолекции + вебинары + домашнее задание + обратная связь от ментора
Итоги	Диплом + проекты в портфолио
Цена	● Полная – 180 000 рублей; ● УСПЕЙ НА СКИДКУ! – 9 000 рублей в месяц; ● рассрочка без первоначального взноса.
Ссылка на курс

Программа курса включает в себя следующие блоки:

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

Преподаватели:

Павел Калаба — Senior Project Manager ПАО “Вымпелком”.

Дмитрий Зверев — бизнес-психолог, PhD НИУ ВШЭ, работал с Кембриджским колледжем, компаниями HeadHunter, Apple, Sony, Samsung и Procter&Gamble.

Виктория Дубешко — senior Project Manager @ Rambler Group.

и еще 8 преподавателей. Полный список здесь.

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

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

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

Получить скидку →