AGILEГИБКИЕ МЕТОДЫ УПРАВЛЕНИЯ ПРОЕКТАМИ

ВВЕДЕНИЕ В ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИ• Сюхари (яп. 守破離 сюхари, от яп. 守 — «соблюдать», 破 —

«прорываться» и 離 — «отделяться») — концепция японских боевых искусств и описание этапов обучения, согласно которым существует понятие о трёх ступенях. Три шага мастерства в боевом искусстве появились в Китае и повлияли на японские боевые искусства. Иногда применяется для других японских дисциплин, например для го.

• Сю (яп. 守 сю, от яп. 守 — «соблюдать») — первая ступень, означающая, что надо заучивать всё точно так, как показывает учитель. Требуется много лет тренироваться, иначе не будет базы для перехода на следующую ступень.

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

• Ри (яп. 離 ри, от яп. 離 — «отделяться») — третья ступень, означает подняться над всем, что изучалось раньше, создать более высокие и более общие принципы.

• Морихэй Уэсиба: Чтобы прийти к высшей правде, нужно непрерывно и всем сердцем добиваться искренности.

2

ВВЕДЕНИЕ В ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИЭВОЛЮЦИЯ AGILE И ВОДОПАДНОЙ МОДЕЛИ

ОПРЕДЕЛЕНИЕ ВОДОПАДА

ОПРЕДЕЛЕНИЕ AGILE

СРАВНЕНИЕ ПЛАНОВЫХ И АДАПТИВНЫХ ПОДХОДОВ

РАННЯЯ ИСТОРИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ

ТРАНСФОРМАЦИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ

ЧТО ДВИЖЕТ ЭТИМИ ИЗМЕНЕНИЯМИ?

ПРЕИМУЩЕСТВА ГИБКОГО УПРАВЛЕНИЯ ПРОЕКТАМИ

ИСТОРИЯ И МАНИФЕСТ AGILE

УИНСТОН РОЙС И ВОДОПАДНАЯ МОДЕЛЬ

3

СИСТЕМНЫЕ ТРЕБОВАНИЯ

ПРОГРАММНЫЕ ТРЕБОВАНИЯ

АНАЛИЗ

ПРОГРАММНЫЙ ДИЗАЙН

КОДИРОВАНИЕ

ТЕСТИРОВАНИЕ

ЭКСПЛУАТАЦИЯ

ВВЕДЕНИЕ В ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИРАННИЕ ИТЕРАТИВНЫЕ И ИНКРЕМЕНТНЫЕ МЕТОДЫ РАЗРАБОТКИ

ДАЛЬНЕЙШЕЕ РАЗВИТИЕ ИТЕРАТИВНЫХ И ИНКРЕМЕНТНЫХ МЕТОДОВ РАЗРАБОТКИ

РАННИЕ МЕТОДЫ ГИБКОЙ РАЗРАБОТКИ:

• Joint Application Design

• Rapid Systems Development

• Rapid Application Development

• Total Quality Management

• New Product Development Game

• Agile Leadership

• Agile Manufacturing

• Agile Organizations (1996).

• Crystal

• Scrum

• Dynamic Systems Development

• Synch-n-Stabilize

• Feature Driven Development

• Judo Strategy

• Internet Time

• New Development Rhythm

• Adaptive Software Development

• Open Source Software Development

• Lean Development

• Agile Unified Process

• Extreme Programming

• Rational Unified Process (RUP)

• Enterprise Unified Process (EUP)

• Agile Unified Process (AUP)

4

ВВЕДЕНИЕ В ГИБКИЕ МЕТОДОЛОГИИ УПРАВЛЕНИЯ ПРОЕКТАМИМАНИФЕСТ AGILE

ЦЕННОСТИ МАНИФЕСТА AGILE

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

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

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

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

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

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

5

ОБЗОР ПРАКТИК AGILEПРАКТИКИ ПЛАНИРОВАНИЯ AGILE

ПЛАНИРОВАНИЕ ПО МЕТОДУ НАБЕГАЮЩЕЙ ВОЛНЫ

СТРАТЕГИИ ПЛАНИРОВАНИЯ

ЗАКРЕПЛЕНИЕ

6

ОБЗОР ПРАКТИК AGILEПОСЛЕДОВАТЕЛЬНОЕ РАЗВИТИЕ

ФУНКЦИОНАЛЬНАЯ ДЕКОМПОЗИЦИЯ НА ОСНОВЕ ЦЕННОСТЕЙ

ГИБКИЕ ПРАКТИКИ ОПРЕДЕЛЕНИЯ ТРЕБОВАНИЙ

РОЛЬ БИЗНЕС-АНАЛИТИКА В ГИБКИХ ПРОЕКТАХ

"ДОСТАТОЧНО ХОРОШО"

ОТЛИЧИЕ ПОЖЕЛАНИЙ ОТ ПОТРЕБНОСТЕЙ И "ПЯТЬ ПОЧЕМУ"

МЕТОД MOSCOW

• Должно быть (Must have). Требования, помеченные как "должно быть", должны быть включены для исполнения на ближайшее время. Если хотя бы одно требование "должно быть" не включено, проект считается как невыполненный.

• Следует быть (Should have). Требования "следует быть" также критичны для успеха проекта, но они не являются обязательными для исполнения в ближайшее время.

• Может быть (Could have). Требования "может быть" являются менее критичные и обычно рассматриваются как желательные.

• Может не быть (Won't have). Требования "может не быть" являются наименее приоритетными, наименее ценными или не подходящими для этого времени.

7

ОБЗОР ПРАКТИК AGILEПЕРСОНА И ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ

ПЕРСОНА ПОЛЬЗОВАТЕЛЯ

ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ

ЭПОПЕИ

СПИСОК НЕВЫПОЛНЕННЫХ РАБОТ ПО ПРОДУКТУ

ОБСЛУЖИВАНИЕ СПИСКА НЕВЫПОЛНЕННЫХ РАБОТ ПО ПРОДУКТУ

8

ОБЗОР ПРАКТИК AGILEПЕРСОНА И ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ

ПЕРСОНА ПОЛЬЗОВАТЕЛЯ

ИСТОРИЯ ПОЛЬЗОВАТЕЛЯ

ЭПОПЕИ

СПИСОК НЕВЫПОЛНЕННЫХ РАБОТ ПО ПРОДУКТУ

ОБСЛУЖИВАНИЕ СПИСКА НЕВЫПОЛНЕННЫХ РАБОТ ПО ПРОДУКТУ

РАЗРАБОТКА, КАЧЕСТВО И ТЕСТИРОВАНИЕ В AGILE

ПРАКТИКИ

РЕФАКТОРИНГ КОДА

ПОСТОЯННАЯ ИНТЕГРАЦИЯ

ПАРНОЕ ПРОГРАММИРОВАНИЕ

РАЗРАБОТКА УПРАВЛЯЕМАЯ ТЕСТИРОВАНИЕМ

ЭКСТРЕМАЛЬНОЕ ПРОГРАММИРОВАНИЕ (XP)

ГИБКИЕ ПРАКТИКИ УПРАВЛЕНИЯ КАЧЕСТВОМ

КЛЮЧЕВЫЕ ОТЛИЧИЯ ГИБКИХ ПРАКТИК УПРАВЛЕНИЯ КАЧЕСТВОМ

ОПРЕДЕЛЕНИЕ "СДЕЛАНО"

9

ТИПОВЫЕ ПРОЦЕССЫ УПРАВЛЕНИЯ КАЧЕСТВОМ В ТРАДИЦИОННОМ УПРАВЛЕНИИ ПРОЕКТАМИ

ТИПОВЫЕ ПРОЦЕССЫ УПРАВЛЕНИЯ КАЧЕСТВОМ В ГИБКОМ УПРАВЛЕНИИ ПРОЕКТАМИ

Интеграция тестирования с разработкой

Тестирование обычно выполняется после разработки и выполняется отдельным подразделением или организацией

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

Подходы к тестированию Более реактивный подход для поиска и исправления дефектов

Более активный подход для предотвращения дефектов

Ответственность за качество Ответственность за качество программного обеспечения воспринимается как лежащая на QA

Вся команда несет ответственность за качество программного обеспечения

Регрессионное тестирование Так как тестирование откладывается до окончания проекта и стабилизации кода, нет необходимости для сложного регрессионного тестирования

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

ОБЗОР ПРАКТИК AGILEРОЛЬ QA ТЕСТИРОВАНИЯ В ГИБКИХ ПРОЕКТАХ

ПРАКТИКИ ТЕСТИРОВАНИЯ AGILE

КОНКУРЕНТНОЕ ТЕСТИРОВАНИЕ

РАЗРАБОТКА НА ОСНОВЕ ПРИЕМОЧНОГО ТЕСТИРОВАНИЯ (ACCEPTANCE TEST-DRIVEN DEVELOPMENT)

ПОВТОРЯЕМОЕ ТЕСТИРОВАНИЕ И АВТОМАТИЗИРОВАННОЕ РЕГРЕССИОННОЕ ТЕСТИРОВАНИЕ

ТЕСТИРОВАНИЕ УПРАВЛЯЕМОЕ ЦЕННОСТЬЮ И НА ОСНОВЕ РИСКОВ (VALUE-DRIVEN & RISK-BASED TESTING)

10

ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИТипичный способ моделирования для традиционных проектов основан на довольно статичных моделях, состоящих из структурной декомпозиции работ, сетевых графиков, диаграмм Ганта и так далее.

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

ВАЖНОСТЬ ИСПОЛЬЗОВАНИЯ ПОТОКОВ РАБОТ

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

11

ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ• Пакеты небольших размеров. Просто подумайте о попытке протолкнуть большое количество

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

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

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

В этом разделе мы обсудим ряд вопросы, связанных с потоками работ:

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

• Kanban, который также предоставляет подходы для оптимизации потоков работ WIP (Work in Process)

• Теория ограничений, является хорошо известным методом, который был разработан Илия

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

ПЛАНИРОВАНИЕ ВРЕМЕНИ (TIME-BOXING)

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

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

ПРЕИМУЩЕСТВА МЕТОДА TIME-BOXING

Существует ряд преимуществ использования метода time-boxing, которые представлены ниже:

• Сосредоточенность. Большим преимуществом метода time-boxing является то, что вы учитесь сосредоточению вашего внимания на работе в специфический период времени

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

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

• Доступное время. Метод time-boxing заставляет вас осознать то, что вы раньше возможно не понимали – сколько времени вы можете отдать для выполнения конкретного проекта

12

ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИДОПОЛНИТЕЛЬНЫЕ ПРЕИМУЩЕСТВА МЕТОДА TIME-BOXING

Кроме этих преимуществ, существует ряд дополнительных преимуществ метода time-boxing, которые могут быть не очевидны с первого взгляда. Time-boxing решает две широко распространенных проблемы производительности:

• Закон Паркинсона гласит: "Работы расширяются таким образом, чтобы заполнить все время необходимое для их завершения". Фиксация времени исключает пустые временные резервы, которые могут существовать в подходах, фиксирующих содержание.

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

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

KANBAN

Kanban является еще одним видом гибких процессов. Но чтобы понять суть процесса Kanban сначала нужно понять разницу между процессами проталкивания и вытягивания (push & pull).

ПРОЦЕССЫ ПРОТАЛКИВАНИЯ И ВЫТЯГИВАНИЯ

Проталкивающие системы полностью планируются заранее. Примером может служить традиционный производственный процесс:

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

• Заказывается необходимое сырье и ожидает передачи в производство

• Производственные ресурсы заранее планируются и выделяются для удовлетворения прогнозируемого спроса в плане производства.

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

13

ГИБКОЕ УПРАВЛЕНИЕ ПРОЕКТАМИС другой стороны, вытягивающие системы в значительной степени зависят от спроса и являются менее планируемыми. Примером может служить процесс производства мебели, в котором процесс построен для удовлетворения требований заказчиков. В идеальной вытягивающей системе:

• Планы относительно слабо определены и находятся в ожидании спроса, а фактические трудозатраты не планируются до получения заказов от клиентов

• Сырье может заказываться только для удовлетворения заказов клиентов

• Производственные ресурсы будут выделяться для выполнения работ только по мере необходимости выполнения заказов клиентов

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

ЧТО ТАКОЕ ПРОЦЕСС KANBAN?

Все гибкие процессы в определенной степени являются адаптивными относительно требований клиентов, вместо полного планирования, однако, идеальный процесс Kanban полностью основан на процессе вытягивания и реагирования на потребительский спрос. Слово Kanban происходит от двух японских слов: Kan – наглядная или визуальная, и Ban – карта или доска. Идея возникла после анализа карт требований, которые иногда используются в производстве. Например, в автомобильной промышленности:

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

• Когда дверец не хватает, он посылает сигнал требования (карта Kanban), чтобы передать это требование предыдущей операции, которая изготавливает дверцы

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

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

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

• Центр обработки заказов

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

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

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

14

ЗАЙЦЕВ АНДРЕЙ ЛЕОНИДОВИЧКлючевые квалификации:

Внедрение и развитие корпоративных систем управления проектами

Внедрение и развитие корпоративных систем управления рисками проектов

Внедрение и развитие корпоративных систем управления ИТ-сервисами

Некоторые реализованные проекты:

ОАО "Ракетно-космическая корпорация "Энергия". Внедрение системы управления проектами.

ФГУП Почта России. Внедрение системы управления проектами.

ОАО "Ильюшин". Внедрение системы управления проектами.

Группа компаний "Ведис Групп". Внедрение системы управления проектами.

Росатом. Внедрение системы управления проектами капитального строительства.

Дополнительная информация:

MCSE, MCPS, MCSA, MCSAM, MCNPS

Действительный член Project Management Institute

Действительный член International Community Project Managers

Действительный член Professional Risk Managers International Association

Действительный член International Institute for Learning

Контактная информация:

Мобильный телефон: +7 909 648 7400

Электронная почта: AndrewZaitsev@Hotmail.com

Skype: Andrew.Zaitsev

15