Agile (эджайл, англ. “гибкий”) - это подход к управлению проектами по разработке ПО. Разработан в середине 2000х годов (или даже раньше). Подход Agile включает в себя несколько методик:

• Scrum (подходит для организации взаимодействия между Бизнесом и ИТ);
• Kanban (подходит для упорядочивания мультизадачности в работе сотрудника; хорошо сочетается со Scrum);
• XP (принципы экстремального программирования);
• Lean (принципы бережливой разработки).

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

Scrum активно применяется в крупных компаниях и корпорациях.

Основная суть процесса следующая:

• проект выполняется короткими итерациями (т.н. спринтами), каждая из которых длится от одной до 4 недель;
• в проекте есть всего 3 роли: Product Owner, Scrum Master, Team. Роли эффективно взаимодействуют друг с другом и ориентированы на сотрудничество.
• в Scrum есть всего 4 артефакта (документа): Product Backlog (требования к продукту), Sprint Backlog (требования, которые будут реализованы в спринте), Sprint Goal (цель спринта, итерации), BurnDown Diagram (диаграмма сжигания работ).
• в Scrum есть всего 4 ритуала. Но читайте лучше об этом в соответствующей статье.

Команда проводит “ритуал” Daily Meeting

Преимущества Agile-подхода:

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

Услуга внедрения Scrum

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

1. Обученных менеджеров вашей компании. Мы проведем обучение для всех сотрудников, которые принимают участие в проектах разработки ПО как со стороны Бизнеса, так и со стороны ИТ. Обучение будет проводиться несколько раз: Бизнес и ИТ, только ИТ, только Бизнес, только команда “пилотного” проекта и т.п. Всего пройдет не менее 5 сессий.
2. Подготовленную Scrum команду. Мы поможем вам сформировать команду, которая будет первой трудиться над пилотным проектом и на примере которой мы покажем эффект. Мы оценим доступность (capacity) команды, предложим её фокус-фактор, подскажем как распределить ресурсы между разными проектами, учтем иные зависимости.
3. Запуск “пилотного” проекта, на котором мы покажем как работает процесс “от и до”. Это самая ответственная часть нашей работы. На примере пилотного проекта выползают все скрытые проблемы, которые мешают вашему бизнесу развиваться (конфликты ресурсов, отсутствие аналитиков, невозможность быстро принимать решение и пр.). Мы подскажем вам как правильно уйти от возникших противоречий и недопустить подобных случаев в будущем.
4. Инструкцию для команд и мастеров. Простой и доступный документ, в котором описаны основные действия, необходимые команде и её окружению, чтобы правильно выполнять все процессы в Scrum.
5. ИТ-окружение. Если у вас есть программное обеспечение для управления проектами, то мы поможем правильно использовать его в проектах, выполняющихся по Scrum.

Как происходит проект внедрения?

Наш подход по внедрению основан на двухнедельных этапах. Мы готовы выполнить проект всего за 3 этапа:

1. Обучение и подготовка к внедрению. Мы готовим ваших сотрудников, оцениваем ваши процессы, помогаем выбрать пилотный проект. Также мы рекомендуем подписать Устав проекта внедрения Scrum, чтобы у всего предприятия было одинаковое представление о границах внедрения.
2. Внедрение Scrum на пилотном проекте. Мы помогаем запустить процесс на вашем пилотном проекте. Проводим дополнительное обучение для команды и владельцев продуктов. Учитываем реальную загрузку команды, влияние других проектов и пр. Также мы разрабатываем инструкцию для Scrum-команд.
3. Сопровождение вашего пилотного проекта. Если требуется проводим повторный инструктаж для команды. Каждый день мы проверяем, правильно ли ваши сотрудники выполняют ритуалы Scrum? Выявленные ошибки корректируются на месте.

Перед началом нашей работы мы согласовываем детальный график работ на первый этап и рекомендуемый график на этапы 2 и 3.

Чем Agile отличается от Scrum?

Если кратко, то Scrum - это одна из Agile-методик.

Scrum подходит.

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

Цена и стоимость внедрения

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

• примите решение о том, какой пилотный проект будет первым переведен на Scrum-рельсы. Это должен быть важный проект для компании, но не самый критичный (риск остановить проект должен быть приемлемым).
• выберите Scrum-мастера. Это должен быть тактичный и неконфликтный человек, который не будет “давить” на команду пилотного проекта. Мастер должен понимать специфику проекта, но не обязательно быть техническим человеком.
• найдите Владельца продукта, который действительно заинтересован в результате проекта внедрения и получении эффекта. Не выбирайте топ-менеджеров, у которых есть куча дел, помимо самого проекта. Будет идеальным вариантом найти сотрудника, чья эффективность и бонус напрямую зависит от скорости появления продукта на рынке.
• освободите для команды проекта место, где они могут работать без “одергиваний” со стороны других сотрудников. Пусть команда сосредоточится только на работе.
• как заказчик проекта будьте постоянно рядом с командой, чтобы иметь возможность быстро решать проблемы.

Компания “Проектный офис” единственная компания в Беларуси, которая обучает и внедряет “гибкие” методики разработки ПО .

Мы помогаем:

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

В классической модели управления Scrum есть три роли, одна их которых носит название Scrum Master (скрам-мастер). Это роль главного человека в той команде, которая в своей работе исповедует «гибкий» управленческий подход. Но нередко (особенно в бизнес-школах и Scrum-сообществах) Мастером - Professional Scrum Master (PSM) - называют человека, который постиг модель Scrum на фундаментальном уровне, принял философию «гибкого» подхода Agile и теперь не только сам может вести проект любой сложности, но и учит этому других. Такие люди получают сертификат (Scrum Master Certification) разного квалификационного уровня (ступени).

В модели Скрам существует три роли:

• Скрам Мастер.
• Владелец продукта (Product Owner).
• Команда (Team).

Каждый «ролевой персонаж» в этом коллективе несёт ответственность за свой «участок работы».

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

Ролевое распределение обязанностей

Команда (Team), которая, как правило, состоит из 6-8 человек, в парадигме Скрам должна самоорганизовываться и самоуправляться, а её работа рассматривается и оценивается как действие единой группы. Внутри команды нет чёткого подразделения на роли с ограничением действий, хотя в команду входят люди с разными профессиональными навыками. Мастер, однако, здесь стоит особняком и не считается членом Team.

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

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

В случае с Product Owner речь почти всегда идёт об одном человеке, который несёт персональную ответственность за создание ценности и поэтому сам корректирует приоритеты на каждом рабочем этапе-спринте. Однако иногда одному человеку исполнять эту роль сложно. Тогда функции «Владельца проекта» распределяются между несколькими людьми (например, один формулирует требования, а другой отвечает за взаимодействие с рынком). Но в этом случае всё равно обязательно назначается главный руководитель с правом (и обязанностью) единоличной расстановки приоритетов и авторизации требований в Bcaklog’e.

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

Сложная роль Мастера

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

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

Роль подобного координатора-администратора в коллективе не нова. Идеологически она чем-то похожа на роль комиссара в военном подразделении. (По этой аналогии функции командира отряда соответствуют функциям Product Owner в Scrum-модели).

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

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

Квалификация Скрам-мастера

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

Так, например, в тренинг-школе «Unusual Concepts» проводится двухдневный курс (Certified ScrumMaster), на котором даются базовые знания о модели. Проходящие обучение получают системные рекомендации по тактике внедрения модели в организации и по содержанию Scrum-процессов.

В частности, «студентов» знакомят со всеми этапами системы и её преимуществами:

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

Помимо этого есть 3-дневные курсы по подготовке руководителей проекта – «владельцев продукта» (Product Owner) и тренинг для Мастеров, по итогам которого выдаётся сертификат Скрам-мастера (PSM I). Это официальный курс от Scrum.org, сертификаты которого признаны во всём мире.

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

• PSM I. Прошедшие обучение на этом уровне демонстрируют фундаментальное понимание формы и содержания Scrum, овладевают концептуальными знаниями.
• PSM II. Люди на этой ступене знаний демонстрируют продвинутый уровень мастерства и могут эффективно применить его на практике даже в сложных ситуациях.
• PSM III. Овладевшие этим уровнем отличаются всеобъемлющими теоретическими и практическими знаниями о Scrum и о ценностях идеологии.

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

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

Приступая к описанию бизнес-процессов, бывает нелегко выбрать нотацию, одинаково понятную как представителям бизнеса, так и техническим специалистам. Стандарт BPMN™ (Business Process Model and Notation) помогает разрешить эту проблему за счет выразительной нотации, позволяющей строить модели бизнес-процессов любой сложности, в том числе исполняемых с помощью специализированных систем.

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

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

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

Курс посвящен изучению основ бизнес-анализа в соответствии с BABOK Guide 3.0 и аккредитован Международным институтом бизнес-анализа (IIBA). В рамках курса объясняются особенности профессии "бизнес-аналитик" и ключевые понятия бизнес-анализа. Рассматриваются задачи, техники и ракурсы бизнес-анализа. Помимо этого, в рамках курса рассматриваются требования к сертификации IIBA и способы подготовки к ней. Курс проводят специалисты-практики с богатым опытом в области бизнес-анализа.

Курс посвящен изучению области знания «Планирование и мониторинг бизнес-анализа» BABOK Guide 3.0 и аккредитован Международным институтом бизнес-анализа (IIBA). В курсе рассматриваются задачи выбора подхода к бизнес-анализу в проекте, определения подлежащих выполнению работ и оценки их трудоемкости, определения причастных лиц и планирования их вовлечения, планирования управления требованиями, а также нахождения возможностей повышения продуктивности работы бизнес-аналитиков. Курс проводят специалисты-практики с богатым опытом в области бизнес-анализа.

Курс посвящен изучению области знания «Выяснение и взаимодействие» BABOK Guide 3.0 и аккредитован Международным институтом бизнес-анализа (IIBA). В курсе рассматриваются задачи выяснения, документирования и предъявления информации бизнес-анализа, а также вопросы взаимодействия с причастными лицами в ходе подготовки к выяснению и подтверждения его результатов. Курс проводят специалисты-практики с богатым опытом в области бизнес-анализа.

Курс посвящен изучению области знания «Управление жизненным циклом требований» BABOK Guide 3.0 и аккредитован Международным институтом бизнес-анализа (IIBA). В курсе рассматриваются задачи трассировки и поддержания актуальности требований, а также их приоритизации, утверждения и повторного использования. Объясняется применение паттернов требований. Обсуждаются вопросы управления изменениями требований. Курс проводят специалисты-практики с богатым опытом в области бизнес-анализа.

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

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

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

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

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

Agile ,

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

Когда я прочитал: «Agile is much more than just Scrum» - в описании сертификационного курса Certified Agile Professional компании ScrumTrek, то первое, о чем я подумал: почему ScrumTrek, тогда уж нужно было назваться AgileTrek? После прохождения этого обучения я вернулся к этому утверждению с более серьезным настроем. Так что же я вынес с тренинга? Записи, раздаточный материал и сертификат Certified ICAgile Professional? А как же понимание, что такое Agile? В чем заключается концепция Agile-подхода? Что такое Agile mindset?

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

История Agile

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

Code-and-Fix позволил стартовать отрасли написание кода относительно дешево без каких-либо планов, документации и специальных требований к квалификации разработчиков.

Ему на смену в 1970 годах пришла водопадная модель (Waterfall), которая снизила риски, повысила прозрачность разработки ПО, а также устранила проблему высокой стоимости сопровождения ПО при сохранении низких требований к квалификации разработчиков. Модель начали использовать повсеместно, что быстро обнажило и ее проблемы. Водопад хорошо работает только в тех случаях, когда заранее все известно: какой продукт необходимо разработать, какие технологии реализации нужно использовать – и никаких изменений по ходу не возникает.

Первые попытки исправить ситуацию связаны с появлением в 1990 годах итеративных подходов. С одной стороны, этому способствует удешевление компьютеров, когда машинное время перестает быть объективным ограничением, что позволяет производить многократные эксперименты по наращиванию функциональности продукта. С другой стороны, новые технологии ИТ все больше и больше усиливают конкуренцию, поэтому бизнесу приходится оперативно применять их в бизнесе. Кто внедрил новую технологию раньше остальных, то завоевал и клиентов, и рынок. С этого момента начинается активное развитие гибких процессов разработки, которые ставят своей целью предоставить бизнесу быстрые поставки функциональности. По сути происходит откат к «быстрому» методу Code-and-Fix, но его дополняют планированием и исключением рисков.

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

Или все же так, как в Scrum?

В 1992 году появляется Crystal, который впервые фокусируется на частой поставке работающего кода конечным пользователям. Затем в 1994 представлен DSM (Dynamic Systems Development Method), который провозгласил ориентацию на потребности бизнеса и неснижаемый уровень качества ПО (примерно в эти же года появился термин Refactoring). Наконец в 1996 году представлен Scrum Framework, который стал стандартом де-факто для управления гибкой разработкой. В этом же году начинает впервые применяться парное программирование. А в 1999 появляется XP, который принес концепцию пользовательских историй (User Story), планирования релизов и непрерывной интеграции (Continuous Integration). Итогом всех этих частных инициатив стал разработанный в 2001 году Agile-манифест разработки программного обеспечения , в котором закреплены проверенные 10-летием ценности и принципы, позволяющие быстро поставлять функциональность бизнесу.

Дальнейшее развитие Agile связано с попытками устранить все возможные потери (простои) в процессе разработки ПО, за счет чего еще больше повысить скорость доставки функциональности. В 2003 появляется Lean Software Development как адаптация концепции бережливого производства Toyota к отрасли разработки ПО. В 2006 движение продолжается за счет появления Kanban Software Development, в котором представлен готовый алгоритм устранения потерь в потоке поставки ценности (функциональности) бизнесу. Также в 2011 году в ответ на взрывной рост SAAS (ПО как сервис) появляется концепция DevOps, которая объединяет разработку и сопровождение для устранения потерь на их стыке.

Итого, производство (разработка) перестало быть узким звеном, научившись максимально быстро удовлетворять потребности бизнеса. Тем не менее, развитие Agile продолжается. Во-первых, в области масштабирования Agile на крупных предприятиях (SAFe). Во-вторых, огромное количество провальных инвестиционных проектов поднимает вопрос в области разработки продуктов: как максимально дешево разработать максимально востребованный продукт? В 2009 году ответом на это ограничение становится Lean Startup.

Ценности и принципы Agile

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

К примеру, вторая ценность Agile: «Работающий продукт важнее исчерпывающей документации». В свое время это было декларацией отрицания водопадной модели, в которой понимание прогресса во многом опирается на проектную документацию. Но во 2 версии Agile-манифеста формулировка изменилась: «Бизнес-ценность важнее работающего продукта» (Agile Manifesto 2.1 - «MoreAgile Manifesto»). Это пример эволюции Agile-ценностей связанный появлением Lean Startup: слишком много работающих продуктов оказывались никому не нужными.

Scrum и Kanban

Значительную часть тренинга занимает обзор Scrum Framework и Kanban. Пересказ этой части тренинга не входит в цели данной заметки. Отмечу только, что каждый нетривиальный момент тренер помогает прочувствовать на кончиках собственных пальцев посредством командной игры. А вот об этом стоит рассказать подробнее.

Игры в Agile

Все игры были простыми в освоении и веселыми в процессе. Во время одной игры на второй день тренинга один из участников воскликнул: «И чем мы раньше занимались? Вот оно!» Ниже я расскажу о том, чему мы научились в играх.

Penny/Multitasking games вживую (на нас самих) и убедительно (обычным секундомером) продемонстрировали необходимость брать в работу малые порции и не выполнять в один и тот же момент времени несколько задач. Мы увидели, как это исключает потери из-за простоев в строго последовательном процессе работы (водопад), потери из-за накопления незавершенной работы (набитый рот дольше жует) и на переключения контекста (в водопадной модели работа сотрудника над несколькими проектами одновременно наиболее вероятна).

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

Игровая постановка саботирования Daily Standup Meeting вернула нас к обсуждению ценностей Agile. К примеру, Scrum Master (процессный коуч) не должен быть менеджером для команды разработки или вести себя соответствующим образом, то есть раздавать задачи, включать эмоции и противопоставлять себя группе, превращая тем самым встречу в унылое отчетное собрание членов команды перед самим собой.

Agile-Scrum Foundation 1

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

В отличие от таких всеобъемлющих подходов к управлению проектами, как, например, стандарты Института Управления Проектами (PMI)® PMBOK® Guide, Скрам изначально предназначался для разработки программного обеспечения в условиях часто меняющихся требований. При этом Скрам (Agile) больше ориентирован на сам процесс разработки, чем на процесс управления. Эта технология хорошо дополняет любой из классических процессов управления и может быть с ним интегрирована при разработке даже очень больших IT проектов. В настоящий момент Agile практики стали частью PMBOK® Guide.

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

Аудитория курса:

• Разработчики программного обеспечения – члены команд разработки, тим-лиды (старшие групп разработки).
• Специалисты, желающие освоить роль Product Owner или Scrum Master в Scrum-командах.
• Менеджмент Scrum-команд, желающий познакомиться с особенностями работ внутри команды.

Курс «Agile-Scrum Foundation 1. Управление проектами с использованием гибких подходов» дает для подготовки к и PDU для продления имеющихся у вас сертификаций :

	Technical	Leadership	Strategic	Total
PMI_RMP ®	-		-
PMI_SP ®	-		-
PMP(r) ®			-
PgMP(r) ®			-
PMI_ACP ®			-
PfMP ®	-		-
PMI_PBA SM	-		-

PMI является зарегистрированной маркой Института Управления Проектами.
PMBoK является зарегистрированной маркой Института Управления Проектами.