В классической модели управления 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 и о ценностях идеологии.

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

Поздравляем! Вы приглашены на собеседование. Независимо от того, является ли это вашей первой работой в сфере Скрам, или же вы опытный профессионал, всегда полезно знать, как подготовиться. К ведущим компаниям, использующим Agile и Scrum, относятся Apple, Google, Valve и Philips, что красноречиво говорит о требуемом уровне знаний.

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

1. Объясните суть Agile за 30 секунд.

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

2. Каковы различия между Agile и традиционным управлением проектами (Waterfall)?

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

3. Вы сертифицированный Scrum мастер?

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

4. Каковы роли в сфере Scrum?

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

5. Что такое «ежедневный Stand-Up»?

Один из вопросов интервью на Agile наверняка будет о ежедневном Stand-Up. Ответ? Каждый день, желательно утром, команда организовывает короткие встречи (примерно по 15 минут), чтобы ответить на три вопроса:

• Что вы делали вчера?
• Что вы планируете делать сегодня?
• Есть ли какие-либо препятствия, которые мешают вам выполнять свою работу?

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

6. Опишите, что происходит на совещании по планированию Спринта.

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

7. Что делает Scrum мастер?

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

8. Есть ли разница между Agile и Scrum?

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

9. Назовите другие гибкие методологии разработки.

Это Kanban, Test Driven Development и Feature Driven Development. Упоминайте методологии , которые знаете.

10. Когда вы должны использовать Waterfall вместо Скрама?

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

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

12. Как долго длятся спринты?

Идеальная длина одного спринта составляет от 1 до 4 недель, при этом наиболее широко используется 2-недельный спринт.

13. Что такое «скорость команды» (velocity)?

Velocity – это среднее количество очков за последние 3-4 спринта. Скорость команды используется, чтобы помочь предсказать, когда будут доставлены элементы бэклога.

14. Все в порядке, если кто-то хочет изменить требование?

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

15. Какие типы показателей или отчетов вы будете использовать?

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

16. Что такое «Диаграмма сгорания задач» (Burndown Chart)?

На диаграмме сгорания отображается объем работы, с которым команда справилась (например, часы спринта). Обсудите, как вы использовали их в прошлом.

17. Что такое ретроспектива?

Это собрание для проверки и адаптации процесса. Будьте готовы объяснить один или два способа проведения ретроспективы.

18. Сколькими Scrum командами вы управляли одновременно?

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

19. Какие требования вы используете для своих команд?

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

20. Опишите моменты, когда участники вашей группы не ладили. Как вы справлялись с этим?

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

Подумайте, как компании-гиганты вроде Cognizant, Phillips и Apple используют методологию Agile Scrum в повседневной практике, и скорректируйте приведенные выше ответы таким образом, чтобы они полностью устраивали нанимающую компанию.

За прохождение курса начисляется 24 PDU.

Описание образовательной программы

Управление проектами как область знаний прочно входит в практику деятельности многих коммерческих и государственных компаний и организаций. Однако, в ходе выполнения ряда проектов, прежде всего в высокоинтеллектуальной сфере, выяснилось, что «классические» подходы проектного управления или работают лишь частично, или не срабатывают вовсе.
Если проекты связаны с решением большого объема аналитических задач, если ситуация в проекте меняется ежедневно или даже ежечасно, если в проекте задействована компактная команда профессионалов из 5-ти/9-ти человек, если в проекте часто изменяется содержание и функционал будущей системы, а выполнить работу необходимо точно в срок и с требуемым уровнем качества, то, возможно, необходимо использовать гибкие (Agile) подходы при управлении проектами. Наибольшую популярность приобрел метод Scrum, успешно применяемый в различных отраслях экономики: информационных технологиях, финансах, обучении, научных исследованиях и т.д.
Курс «Управление Agile-проектами по методу Scrum» призван дать команде проекта инструментарий для более эффективного планирования, исполнения и контроля высокотехнологичных проектов с использованием самых передовых гибких методов.
После изучения курса слушатель будет:
Знать:

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

Уметь:

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

Владеть:

• навыками составления Бэклога Продукта;
• навыками составления Бэклога Спринта;
• навыками проведения совещаний в Scrum - проектах;
• навыками демонстрации результатов.

Успешное окончание обучения по программе данного курса позволит специалистам:
Управлять общим ходом Scrum - проекта.

Цель курса

Формирование и совершенствование профессиональных компетенций в области выполнения проектов по методу Scrum

Целевая аудитория

Специалисты, чья деятельность связана с проектами разработки и/или внедрения информационных систем (ИС):

• менеджеры и аналитики,
• члены проектных команд

Необходимая подготовка

• Опыт участия в проектах разработки и/или внедрения ИС.
• Желательно иметь знания и навыки в объеме курса УП130 «Основы управления проектами» или прослушать этот курс

1. Введение в гибкое (Agile) управления проектами.
2. Основы управление проектами по методу Scrum.
3. Общее описание метода Scrum.
4. Жизненный цикл Scrum - проекта.
5. Определение Спринта (Sprint).
6. Основные артефакты Scrum - проекта.
7. Организация проекта по методу Scrum
8. Роли, внешние к проекту. Заинтересованные стороны (Stakeholders). Заказчик проекта (Customer), Спонсор (Sponsor), Потребители конечной продукции (Users)
9. Роли проектной команды (Скрам-команда, Scrum Team). Владелец продукта (Product Owner). Скрам Мастер (Scrum Master). Команда разработчиков (Development Team).
10. Жизненный цикл Scrum - проекта
11. Инициация. Создание приоритезированного Бэклога Продукта (Product Backlog).
12. Планирование и оценка. Разработка и оценка Пользовательских Историй (User Stories). Формирование и оценка Задач (Tasks). Планирование Спринта. Planning Poker.
13. Исполнение. Создание результатов проекта. Структура Спринта, Focus Factor. Проведение Ежедневных встреч Скрам - Команды (Daily Scrum Meeting).
14. Контроль. Обзор Спринта (Sprint Review). Ретроспектива Спринта (Sprint Retrospective). Отмена Спринта.
15. Завершение. Принятие результатов проекта. Ретроспектива проекта (Project Retrospective).
16. Дополнительные аспекты управления проектами по методу Scrum
17. Управление изменениями. Внесение изменений в Scrum - проекты. Изменения в ходе Спринта.
18. Управление качеством. Grooming (Уход за Бэклогом продукта). Spike (Enabler - история).
19. Управление рисками. Управление рисками в ходе проекта по методу Scrum.
20. Документы в проектной деятельности

Практические занятия

1. Элементы Жизненного цикла Scrum - проекта.
2. Составление Бэклога Продукта. Декомпозиция и приоритезация Пользовательских Историй.
3. Планирование этапа работ (Sprint), составления Бэклога Спринта. Оценивание Пользовательских Историй (User Stories) и Задач (Tasks).
4. Исполнение этапа работ. Ежедневные Командные встречи (Daily Scrum Meeting).
5. Демонстрация полученных результатов Заказчику (Sprint Review Meeting).
6. Совещание по итогам этапа работ (Sprint Retrospective Meeting).
7. Управление Scrum - проектом и этапами работ. Работа с инструментами визуализации: Доска Задач (Tasks Board) и Диаграмма сгорания Задач (Burndown Chart). Оценка производительности.
8. Управление рисками в 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 (процессный коуч) не должен быть менеджером для команды разработки или вести себя соответствующим образом, то есть раздавать задачи, включать эмоции и противопоставлять себя группе, превращая тем самым встречу в унылое отчетное собрание членов команды перед самим собой.