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

Что такое Аджайл

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

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

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

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

Как появился Аджайл

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

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

Чтобы найти формулу работающих продуктов, в 2001 году 17 практиков современных подходов собрались в горной деревушке Сноубёрд. Они обсудили свои способы управления и поняли: подходы у всех разные, но идеи совпадают. Эти идеи заложили в основу Аджайла, внесли в Аджайл Манифест и дополнили Принципами Аджайла .

В чём суть философии Аджайла

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

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

Аджайл - это быть командой самостоятельных профессионалов

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

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

Аджайловая пекарня Владелец пекарни объясняет, почему нужны новые пирожные и какая себестоимость будет выгодна. Продавцы уточняют, какую выпечку ждут покупатели. Закупщики предлагают продукты, на которые сейчас выгодные цены. Процесс строится вокруг экспериментов. Команда придумывает рецепт, печёт пробную партию и получает обратную связь.

Аджайл - это работа с клиентами и готовность изменить первоначальный план

Результат тоже разный. Непредсказуемый у одних и гарантированно хороший у других:

Аджайл - это выпуск работающих продуктов, которые нравятся всем

Идеи Аджайл Манифеста и Принципы Аджайла помогли пекарне наладить производство новой выпечки. Но крайности в идеологии вредны - неверно думать, что Аджайл отрицает регламент и планирование. Всё это есть, однако играет меньшую роль, чем живое общение людей и гибкость в работе.

Что даёт Аджайл

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

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

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

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

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

При чём тут Скрам и Канбан

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

Чтобы применить философию Аджайла на практике, используют Скрам, Канбан и другие способы управления. Это правила, которые объясняют, как организовать работу в духе Аджайла. Они бывают разной степени конкретности. Например, в Канбане шесть общих правил , а в Скраме описаны роли, события и артефакты . Их можно расширять и адаптировать, главное, следовать ценностям Аджайла.

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

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

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

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

История Agile

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

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы. К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD). Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

В феврале 2001 года семнадцать разработчиков ПО встретились на курорте Snowbird в штате Юта, чтобы обсудить легкие методы разработки. Вместе они опубликовали Манифест о гибкой разработке программного обеспечения Agile.

Манифест Agile

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

4 идеи Agile

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

12 принципов Agile

1. Удовлетворенность клиентов за счет ранней и непрерывной поставки программного обеспечения. Клиенты более счастливы, когда они получают рабочее программное обеспечение через регулярные промежутки времени.
2. Вносить изменения требований к продукту на протяжении всего процесса разработки.
3. Частая поставка рабочего программного обеспечения (каждый месяц, две недели, неделю и т.д.).
4. Сотрудничество между заинтересованными сторонами (заказчиком и разработчиками) на протяжении всего проекта.
5. Поддержка, доверие и мотивация вовлеченных людей. Мотивированные команды с большей вероятностью выполняют свою лучшую работу, чем сотрудники, недовольные условиями труда.
6. Взаимодействие лицом к лицу. Коммуникация более успешна, когда команды разработчиков имеют возможность общаться напрямую.
7. Рабочее программное обеспечение является основной мерой прогресса. Предоставление функционального программного обеспечения клиенту является конечным фактором, который измеряет прогресс.
8. Поддержка постоянного темпа работы. Команды устанавливают повторяемую и поддерживаемую скорость работы, с которой они могут доставлять функционирующее программное обеспечение.
9. Внимание к техническим деталям и дизайну. Правильные навыки и хороший дизайн позволяют команде поддерживать темп, постоянно совершенствовать продукт и работать над изменениями.
10. Простота.
11. Самоорганизующиеся команды поощряют отличную архитектуру, требования и проекты. Квалифицированные и мотивированные члены команды, которые обладают полномочиями принимать решения, регулярно общаются с другими членами команды и обмениваются идеями, которые обеспечат создание качественного продукта.
12. Постоянная адаптация к изменяющимся условиям, что поможет сделать продукт более конкурентоспособным на рынке.

Основа метода Agile

Основой метода гибкого управления проектами является ряд ключевых элементов:

1. Визуальный контроль. Участники проекта в ходе работы над проектом используют карточки различных цветов и видов, которые сигнализируют, какой элемент конечного продукта уже разработан, спланирован, завершен и т.д. Таким образом, команда имеет наглядное представление о существующем положении дел. Визуальный контроль обеспечивает одинаковое видение проекта каждым из участников.
2. Все участники проекта работаю рядом, включая клиента. Такой подход не только ускоряет многие процессы, связанные с информированием участников рабочей группы, но и создает благоприятную атмосферу для сотрудничества и эффективной работы.
3. Адаптируемое управление. Руководитель проекта – не человек, который раздает указания, а лидер, определяющий основные правила работы и сотрудничества.
4. Совместная работа. Команда, руководитель проекта и клиент работают сообща, что исключает возможность потери информации и непонимания целей. Также прозрачность всех процессов позволяет моментально исключать появившиеся проблемы и находить удачные решения и улучшения.
5. Работа, основанная на разделении общего объема проекта на составные части. Такая система работы значительно снижает сложность проекта и позволяет командам сфокусироваться на каждой части в отдельности.
6. Работа над ошибками. В ходе работы одного цикла команда осваивает новые навыки и анализирует произошедшие ошибки, что исключает их появление в следующем цикле.
7. Спринты и ежедневные встречи. Спринты – отрезки времени, за которые команды выполняет ряд задач, — позволяют четко видеть результаты работы. Разделив время работы над проектом на спринты, получаем, например, 10 спринтов, каждый по две недели. А ежедневные встречи не более чем на 15 минут помогут каждому члену команды ответить для себя на три вопроса: что я делал вчера, что я буду делать сегодня, что мне мешает выполнять работу?

Таким образом, внедрение гибкого метода Agile возможно при следующих условиях:

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

На данный момент методология Agile широко распространена в IT-сфере и начинает осваивать деловую сферу, в частности маркетинг, менеджмент, обучение и т.д.. Метод гибкого управления проектами используется многими компаниями и госструктурами, например, правительства Норвегии и Новой Зеландии применяют Agile. В России «Сбербанк» осваивает Agile для коммерческой сферы.

Системы управления проектами, основанные на Agile

Существует множество методов, основанных на идеи Agile, самые популярные из них — Scrum и Kanban.

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы. Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч. Сам метод представляет собой процесс разработки, разделенный на небольшие итерации — спринты, по завершении которых пользователи получают улучшенный вариант ПО. Спринт жестко фиксирован по времени, а его длительность составляет от 2 до 4 недель. Работа в рамках одного спринта состоит из нескольких этапов:

1. Планирование объемов работы для одного спринта.
2. Ежедневные совещания на 15 минут для коррекции работы команды и подведения промежуточных итогов.
3. Демонстрация результатов работы.
4. Ретроспектива спринта, в которой рассмотрены удачные и неудачные события в рамках прошедшего спринта.

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

Scrum значительно увеличивает производительность и сокращает время до преимуществ по сравнению с классическими процессами «waterfall». Процессы Scrum позволяют организациям плавно адаптироваться к быстро меняющимся требованиям и создавать продукт, отвечающий изменяющимся бизнес-целям. Scrum позволяет:

• Повысить качество результатов;
• Лучше справиться с изменениями;
• Обеспечить более точные оценки, тратя меньше времени на их создание;
• Лучше контролировать сценарий проекта и этапы работы.

Kanban

Kanban — это процесс, призванный помочь командам работать вместе более эффективно. В переводе с японского kanban обозначает “рекламный щит, вывеска”, а сам метод взят и адаптирован с производственной системы Toyota. Суть Канбан заключается в том, чтобы сделать процесс разработки максимально прозрачным и распределять нагрузку равномерно между членами команды. Канбан способствует непрерывному сотрудничеству и поощряет активное, постоянное обучение и совершенствование.

Kanban основан на трех принципах:

1. Визуализация задач: видимость всей информации о проекте поможет увидеть недочеты, ошибки и накладки.
2. Контроль и ограничение WIP (work in progress — работа, выполняемая одновременно): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не совершали слишком много работы сразу.
3. Контроль времени на выполнение задачи и оптимизация работы для экономии времени.

Достоинства и недостатки Agile

Любая методология имеет преимущества и недостатки. Рассмотрим плюсы и минусы Agile.

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

1. Больше гибкости по сравнению с методологией Waterfall.

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

2. Меньше дефектов в конечном продукте.

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

Недостатки

1. Постоянное получение обратной связи приводит к постоянному переносу даты завершения проекта.

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

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

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

3. Частые встречи

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

Внедрение Agile

1. Выбор методики. Существуют различные гибкие методологии, которые разработаны под определенные условия. Первым этапом работы с Agile необходимо определить цели задачи работы, сроки, количество сотрудников и многое другое и подобрать такую гибкую методику управления проектом, которая будет отвечать всем требованиям.
2. Обучение персонала. Обучение необходимо для того, чтобы сотрудники понимали базовые принципы Agile и знали как с ними работать. Именно на этом этапе определяются подводные камни, которые могут снизить эффективность Agile. Готов ли коллектив к изменениям? Подходят ли проекты компании для гибких методик? На эти и многие другие вопросы обычно помогают ответить бизнес-тренеры, специализирующиеся на Agile. Помимо прочего будет также составлен список тренингов и план, по которому будет вестись внедрение Agile в компании.
3. Демонстрация Agile. Своеобразный тест-драйв Agile, которые проводится под контролем специалиста и показывает все этапы работы, объясняет функции ролей, взаимодействие внутри команды и между командами и т.д.
4. Создание команды. В создание команды помимо подбора сотрудников также входит определение обязанностей, распределение задач, создание графика встреч и т.д. Каждая из методик рассчитана на определенное количество человек в команде.
5. Выбор инструментов , необходимых для распределения задач, ведения отчетности, аналитики и прочее.
6. Первый проект с Agile. В первом проекте будут ошибки, несостыковки, отказ от одних инструментов и выбор других. Любая методика требует своеобразной адаптации под особенности компании, в которую она внедряется.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

• В 1991 году появился метод быстрой разработки приложений RAD
• В 1994 году появился метод разработки динамических систем DSDM
• В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
• В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
• В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

1. Люди и их взаимодействие важнее, чем процессы и инструменты
2. Рабочее ПО важнее, чем документация
3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
4. Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

1. Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
2. Изменять требования к конечному продукту в течение всего цикла его разработки
3. Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
4. Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
5. Поддерживать и мотивировать всех, кто вовлечен в проект (если , она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
6. Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
7. Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
8. Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
9. Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
10. Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
11. Позволять членам команды (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
12. Постоянно адаптироваться к меняющейся среде (благодаря этому конченый продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

• Что я делал вчера?
• Чем я буду занят сегодня?
• Что мешает мне работать?

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

1. Четко обозначается значение проекта
2. В процессе реализации активно участвует клиент
3. Общий объем работ выполняется пошагово
4. Ориентироваться следует на конкретный результат
5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что этоJ).

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

Популярные методы управления проектами

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

Среди всех методов системы Agile Scrum отличается тем, что делает основной упор на качественный контроль рабочего процесса. Впервые описавшие его японские специалисты по стратегическому менеджменту Хиротака Такуэти и профессор в области научно-технических знаний Икуджиро Нонака называют метод «подходом в рэгби», где Scrum является «борьбой за мяч».

Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:

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

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

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

Метод Kanban

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

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

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

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Доктор Ройс создал так называемую водопадную модель разработки программных продуктов. Она быстро завоевала популярность на Западе, и некоторое время назад по этой модели работало подавляющее большинство компаний-разработчиков. Что она собой представляет? Разработка продукта проходит через ряд этапов:

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

В идеальном мире мы прошли бы по этим уровням сверху вниз, как течет водопад, и в конце у нас получилась бы хорошая система. В чем заключалось решение доктора Ройса? Он предложил писать много документации, обрабатывать риски, повторять по несколько раз какие-то этапы. В итоге получилась тяжеловесная водопадная модель. Вся индустрия коммерческого софта сформировалась в 1990-х годах. И если в Европе и США существовали тяжелые методологии, то у нас не было никаких. Собиралась группа людей, которые просто пытались сделать хороший софт. Обе проблемы - отсутствие методологии у нас и тяжеловесные схемы на Западе - хорошо решает Agile.

Для чего нужна методология гибкой разработки?

Итак, для чего же применяется методология Agile?

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

Ответом на все эти вызовы явился Манифест гибкой разработки ПО.

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

• Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается - рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры - JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
• Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
• Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время - материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
• Готовность к изменениям во взвешивании со следованием первоначальному плану.

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

Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой - поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:

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

12 принципов Agile

Ценности влекут за собой 12 принципов Agile:

1. Наивысшая ценность - это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки - от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день. В HeadHunter обычно ежедневно выходит несколько релизов, что создает большие проблемы для наших конкурентов. Это могут быть правки багов, но мы умеем добавлять что-то ценное для наших пользователей.
4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Например, программисты в HeadHunter должны понимать, как работает HR, и как соискатели ищут работу. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой, по моему опыту, является недоступность бизнеса - когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
5. Команда - один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
6. Есть много исследований, которые показывают, что лучшее общение - лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя - поговорить с ними.
7. Работающий продукт. Про него повторяться не буду. Степень готовности проекта должна измеряться не словами, о том, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.

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

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

Практики

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

1. На первом месте стендапы . В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
2. На втором месте планирование итераций , когда команда планирует объем работ на ближайшую итерацию. Это к вопросу о том, что в Agile нет планирования. Если у нас итерация идет две недели, то мы пытаемся сделать план, декомпозицию, может быть, разбить бизнес-задачи на задачи технические.
3. Unit-тестирование - одна из самых простых инженерных практик, которую можно достаточно быстро начать использовать. При наличии проблем с качеством порядка 60-70% багов можно отловить unit-тестированием.
4. Планирование релизов . Здесь мы уже планируем большими кусками - что и когда выпустим. Если речь идет о Scrum, то измеряем большими мазками, в спринтах.

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

Нам надо дойти из точки А в точку Б. «Дойти» - означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель - фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель - это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.

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

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

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

Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.

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

Scrum

У Хенрика Книберга есть такая метафора - Agile-зонтик. Это те методологии, которые являются гибкими. Самая большая - Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban. Более половины компаний, применяющих Agile, используют Scrum. На втором месте комбинация Scrum и XP, когда берутся управленческие практики из Scrum и добавляются инженерные. Отдельно отмечу, что комбинация Scrum и Kanban используется примерно в 8% компаний. Сейчас это один из трендов, мода. Название Scrum пришло из регби и переводится как «схватка». Проще говоря, при возникновении спорной ситуации команды выстраиваются, вбрасывается мячик, и нужно друг друга перетолкать. К разработке продукции этот термин впервые применили в 1980-х годах два японца - Хиротака Такэути и Икудзиро Нонака. Это хорошие исследователи в области менеджмента. В частности, они написали документ «The New New Product Development Game». Здесь употребление слова «new» 2 раза не является ошибкой. Просто название переводится как «Новая игра для разработки новых продуктов». Что сделали эти два японца? Они проанализировали, как различные компании создают свои продукты. Причем даже не ПО, а всевозможную технику и электронику. Авторы разделили выявленные подходы на три типа.

• Первый тип (A): у нас есть фаза разработки, все жестко, последовательно и хорошо.
• Второй тип (B): связи пересекаются, есть возможность получить обратную связь. Я запрограммировал что-то, программирую еще, отдаю тестировщику, он дает свои комментарии, я успеваю их обработать до завершения своей работы.
• Третий тип: каждая фаза пересекается более чем с одной другой фазой. Я программирую еще что-то, а мои первые задачи тестируются, выкладываются в production, с них снимаются метрики, я могу внести изменения.

Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.

Современный Scrum создан двумя айтишниками - Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:

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

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

Компоненты Scrum

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

• Почему мы говорим, что Scrum - это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта - новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
• Владелец продукта, product manager - человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
• Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.

Процессы

• Ежедневный скрам - это планерка, на которой члены команды рассказывают, что сделано, с какими проблемами столкнулись, что планируется сделать в ближайшее время, чтобы каждый понимал, кто и что делает.
• Спринт - итерация с фиксированным сроком, то есть в Scrum должен быть ритм.
• Планирование спринта. Перед началом спринта все собираются и определяют, что нужно сделать в течение спринта и в каком виде.
• Обзор спринта или демонстрация: все собираются и демонстрируют, что нового в инкременте продукта, смотрят, фиксируют замечания, может быть, меняют ближайшие планы.
• Ретроспектива: все собираются и думают, что можно улучшить в следующем спринте. Например, было много багов, пользователи недовольны. Давайте попробуем в следующем спринте использовать модульное тестирование. Пробуем, на следующей ретроспективе смотрим, помогло или нет, придумываем что-то еще.

Бэклог спринта - верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1-4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.

Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».

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

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

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

Примеры Scrum-практик: оценки

Здесь не будет канонического/кошерного/ванильного Scrum"а, который описан Швабером и Сазерлендом, и про который можно почитать здесь: www.scrumguides.org . Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа. Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска. Я много наблюдал, как команда, тимлиды и менеджеры пытаются предсказать, когда у них будет готов проект. Это примерно то же самое, что подойти к команде и попросить назвать случайное число.

Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном - она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой - она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.

Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.

Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.

Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.

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

Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант - работать с заказчиком по системе «время - материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время - материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.

Примеры Scrum-практик: скорость команды

Мы берем каждый спринт, измеряем, сколько story point сделали. И если нам надо спланировать девятый спринт, то просто берем среднее значение из предыдущих спринтов. Это называется «принцип вчерашней погоды». Здесь важно то, что мы набираем наиболее важные или ценные задачи исходя из скорости команды.

Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.

Примеры Scrum-практик: путевой контроль

Как во время спринта контролировать, что у нас все идет хорошо? Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.

По горизонтали отмечаем дни - это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой - истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии - это линия идеального Burn Down Charts. Что эти линии означают? Верхняя - сколько мы сделали историй пользователей, нижняя - количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.

Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20-25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью - очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.

Идут небольшие отставания, но это у хорошей команды. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.

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

Примеры Scrum-практик: доски задач

Обычно в Scrum используют доски задач, хотя они не являются обязательным элементом. Команда распределяет задачи по отдельным этапам и размещает на доске в виде отдельных карточек. Есть электронные реализации досок задач, плагины для JIRA и т.д. Задачи упорядочиваются по степени важности. Когда команда собирается с утра, обновляются статусы задач, их переносят на другие этапы, смотрят, есть ли где-то затыки.

Примеры Scrum-практик: обзор спринта

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

Примеры Scrum-практик: ретроспектива

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

Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача - растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап - сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус - вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5-10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.

На ретроспективе можно также понять моральный дух команды - для этого тоже есть инструменты. Можно просто начертить временную линию спринта, чтобы каждый член команды вспомнил, что происходило в этот день, наклеил стикер с фактом «закончил разрабатывать задачу», «исправлял быдло-код», «применил новую технологию Machine learning». После этого по каждому факту можно внизу нарисовать, насколько этот факт был для человека интересным, или, наоборот, отстойным. После этого построить медиану, которая отразит состояние и динамику морального духа команды.

Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan - Do - Check (Study) - Act.

• Планирование (Plan).
• Реализация (Do).
• Проверка (изучение) (Check (Study)).
• Изменение (Act).

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

После этого можем вносить изменения: например, хотели сделать покрытие 50% - сделали, количество багов уменьшилось, но они еще остались - давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем - улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы - Real-Time Board Service.

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

Напоследок о Scrum

Надо сказать, что Scrum, как и все гибкие методологии, лучше работает в командах, которые сидят в одной комнате. Тем не менее в сети можно найти сотни презентаций о том, как применять гибкие методологии в распределенных командах, когда люди работают на удаленке. Здесь идея такая: вместо реального общения максимально использовать программные и аппаратные инструменты. Что обычно используют? Во-первых, общий трекер, что-то типа JIRA. Это действительно помогает. Популярны программистские чаты, например, HipChat. Для общения - Skype, Hangout. Главное, чтобы была видеосвязь, и чтобы можно было демонстрировать экраны своих компьютеров.

Kanban

Это вторая по популярности методика. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban. Наверное, это один из будущих трендов. Историческая справка: Kanban появился в Японии. Этим словом называлась бумажка с пул-запросом на какие-то действия. Например, мне нужна какая-то деталь, на нее делается отдельный канбан. Но в IT это все-таки применяется немножко в другом виде.

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

В айтишном виде Kanban появился в 2010 г., то есть это достаточно свежая, хорошо описанная методология. Ее автор - Дэвид Андерсон. В следующем году, скорее всего, выйдет обновленная версия методологии. Если Scrum подразумевает жестко предписанные процессы, которые должны сломать то, что было в организации до этого, то есть «Так, все мы теперь работаем по спринтам, с утра приходим, стендапимся, в конце спринта показываем демонстрацию», то Kanban подразумевает более эволюционные изменения.

• Начинаем с того, что есть сейчас, и дальше путем эволюции и постепенных изменений делаем из этого непонятного хаоса четко настроенную Kanban-систему. При этом стараемся только эволюционно изменять роли, зоны ответственности и обязанности. Поощряем инициативные действия на всех уровнях организации. Главная практика - визуализация, обычно в виде доски. Работа каждого члена команды должна быть визуализирована, видна всем.
• Количество работы в каждом процессе ограничивается. То есть в работе одновременно может быть не более какого-то количества задач. Это нужно для исключения мультитаскинга, который убивает эффективность. К тому же это дает определенные инструменты управления потоком задач.
• Все правила должны быть явными. Необходимо дать определение завершенности. Например, задача выполнена, если написан код, есть unit-тесты с покрытием 70%, и т.д.
• Необходимо делать улучшения с помощью постоянных экспериментов, используя модели и научный подход, в том числе цикл Деминга.

Визуализация

Обычно используется та же самая доска, что и в Scrum. Самый простой вариант - прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач - WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».

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

Здесь есть те же самые WIP, внизу - критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.

Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали - количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них - WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.

Вторые важные критерии - Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.

В данном случае Lead Time включает в себя ожидание, то есть как воспринимают вашу Kanban-систему заказчики. Cycle Time - насколько быстро задача проходит через Kanban-систему без ожидания, в общем бэклоге. Оба параметра нужно уменьшать, тогда ваша система будет работать быстрее.

Итог

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

• «Scrum и XP: заметки с передовой». Автор - Хенрик Книберг, Agile-коуч из компании Spotify. Книга полностью бесплатна и на русском языке. Ее минус - она очень старая. Ее большой плюс - в ней разобрано много инструментов, приведены конкретные ситуации в виде диалогов. Книгу очень любят практики, и для многих, в том числе для меня, это была первая книжка на тему Scrum и Agile. Также в ней описаны элементы экстремального программирования.
• «Scrum и Kanban: выжимаем максимум». Тоже на русском и бесплатная. Можно сказать, что это книга про Scrumban.
• На мой взгляд, лучшей книжкой по Scrum является «Scrum: гибкая разработка ПО» Майка Кона. В ней очень подробно расписано, как внедрить Scrum, кем должны стать менеджеры, архитекторы. Самая подробная книга на эту тему.
• И такая каноническая книга по Kanban Дэвида Андерсона - «Kanban: Successful Evolutionary Change for Your Technology Business». В следующем году выйдет обновленная версия.
• Моя книга «

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

Общая информация

Первоначально давайте разберёмся с техническими моментами. Что собой представляет Agile? Перевод (дословный) этого слова с английского языка - «живой, подвижный», немногим реже упоминается «гибкий». И кстати, это сокращение. Полное название этого подхода это Agile software development. Но поскольку это слишком долго, то и было решено сократить. И сейчас говорят просто Agile. Перевод как «гибкий» используется из-за того, что он в наибольшей мере соответствует реальной ситуации.

Что же сюда включено?

Продолжаем рассматривать, что такое Agile. Здесь хочется сконцентрировать внимание на том, что это гибкий подход, в основе которого лежит множество различных ХР, "Канбан", Lean). Для того чтобы лучше разобраться в теме, давайте проведём параллели. Допустим, что Agile-технологии - это процесс зарождения Вселенной. Конечный продукт - непосредственно сам существующий мир. А большой взрыв - это наиболее болезненная проблема, с которой только приходится встречаться, - изменение перечня требований к продукту. Обычно процессы создания подразумевают использование каскадной модели. В этом случае всё идёт последовательно и по этапам. Такой подход можно выразить кратко: вижу цель - иду к ней. И если меняются требования к конечному результату, то иногда приходится переделывать заново едва ли не всё. Что еще усложняет такую ситуацию, так это попытка сделать вид, что всё нормально, и нужно двигаться вперед.

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

1. Главное - это люди, а не вещи.
2. Сотрудничайте, а не читайте контракт.
3. Документация не должна мешать работать.
4. Меняйтесь настолько быстро, насколько это возможно.

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

Устройство процессов

Рассматривая, что такое Agile, давайте обратимся к одной из самых популярных методичек, известной как "Скрам" (Scrum). Что же она предлагает? Для начала нужно:

1. Выбрать владельца продукта. На эту роль подходит человек, что видит, к какой цели нужно идти, и что будет в конечном итоге.
2. Определиться с командой. Для этого необходима группа, численностью от трех до десяти человек, что владеют навыками, позволяющими получать результат.
3. Выбрать ответственного специалиста. Это человек, что будет следить за развитием проекта и помогать команде обходить трудности.
4. Разобраться с трудностями. Следует собрать в одном месте все существующие требования к продукту и расставить приоритеты. Владелец продукта должен собрать здесь все свои пожелания. Потом команда их оценивает и разбирается, можно ли это реализовать, и сколько времени для этого нужно.
5. Следует разбить весь объем работ на отрезки времени, длиной в неделю или две, во время которых команда будет выполнять определённые наборы задач.
6. Ежедневно следует проводить встречи, длиной не более пятнадцати минут. На повестке следует обговаривать, что было сделано вчера, какие планы на сегодня, и преграды, мешающие брать высоту.
7. Делать обзоры по итогам недели (двух), во время которых командой рассказывается о том, что было сделано. При этом необходимо демонстрировать работоспособность частей продукта.
8. После каждого временного периода необходимо обсуждать проблемы и искать решения. Причем все наработки необходимо внедрять сразу.

Как опознать Agile?

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

1. Минимизация рисков. Это главная цель, которую преследует любой гибкий подход.
2. Итеративная разработка. В данном случае подразумевается работа в небольших циклах.
3. Самое важное - это люди и коммуникация между ними.

Давайте представим реку. На одном берегу заказчик. На втором - команда. В таком случае гибкая методология разработки имеет преимущества для всех:

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

Социальный фактор

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

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

Небольшой пример

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

Поскольку используется гибкая методология разработки, то пользовательские истории не копятся до большого релиза, а выпускаются сразу после завершения и как можно чаще. Количество обработанных обращений составляет пропускную способность команды на неделю. Чтобы не потерять темп и не увязнуть в ручном тестировании, команда должна работать над автоматизированной интеграцией. В чем она заключается? Для каждого рабочего момента пишется автоматический тест. Если историй слишком много, то может возникнуть спешка, потеря мотивации, снижение производительности и качества. На такие случаи предусмотрен метод «вчерашняя погода». Он заключается в том, что нужно установить жесткие рамки количества работы и тщательно выбирать, что именно будет реализовываться. Упомянутый ранее "Канбан" предлагает устанавливать лимит задач.

А что делать с очередью?

Ладно, вот команда решила, что она может обрабатывать четыре истории на неделю. Но как сориентироваться во всём, что есть? Допустим, пользователи подкидывают по десять историй на неделю. Обрабатывается четыре. Таким образом, очередь будет постоянно расти. На этот случай есть только один эффективный метод - слово "нет". Для владельца продукта это чрезвычайно важно. Сказать «да» не трудно. Значительно сложнее и важнее решить, что не нужно делать. Причем за это необходимо ещё и нести ответственность. Поэтому следует решать, чему уделять внимание сейчас, а что следует отложить. Чтобы правильно нужно чтобы владелец продукта понимал ценность и объем каждой истории.

Принимаем решения

Часть историй чрезвычайно нужна. Другие же просто представляют собой приятный бонус. Одни истории будут разрабатываться несколько часов. На создание других уйдут месяцы. Многие часто проводят соотношение между размером истории и её ценностью. Но это не всегда правильно. Больше - не равнозначно лучше. Петру правильно рассматривать приоритеты помогает сложность и ценность выполняемой задачи. Как определить эти характеристики в количественном значении? Да никак. Это настоящая игра в угадайку. И для большей эффективности в неё необходимо вовлекать достаточно много людей. Это и команда разработчиков, которая проинформирует про объем работ, и заинтересованные лица. Но следует понимать, что все данные, полученные таким способом, представляют собой приблизительные догадки. Здесь не бывает точных цифр. Первоначально будут промахи. Но по мере получения опыта их количество и масштаб будут понижаться.

Возможные риски

Для избегания проблем необходимо дать честные ответы на ряд вопросов. Это:

1. Правильные вещи ли мы делаем? Это бизнес-риск.
2. Можем ли мы реализовать то, что нужно?
3. Будет ли работать проект на данной платформе. Это технический риск.
4. Хватит ли денег, и успеем ли? Это риски сроков реализации и стоимости.

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

Как обучиться?

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

Что ждёт в будущем?

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

В заключение

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