Эта статья, в отличии от других раскрывающих особенности применения Метода, пытается ответить на вопрос “А является ли Метод управления проектным бизнесом Agile-подходом?”. По каким критериям можно понять, что такое Agile-подход, а что нет?
Для ответа на этот вопрос давайте сверимся с “Манифестом адаптивной разработки программного обеспечения”. https://agilemanifesto.org/. И по пунктам разберем, какие инструменты и Правила Метода реализуют принципы Манифеста.
Основополагающие принципы Agile-манифеста
Мы следуем таким принципам:
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
Тут следует разделить
1.1 Цель “удовлетворение потребностей заказчика” обеспечивается: “Правила запуска проекта” – соглашение о целях проекта.
1.2 Цель “регулярной и ранней поставке” обеспечивается правилами “Качество работы”, “Правила непрерывного проектирования”,”Совещание по планированию спринта”.
Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
Обеспечивается правилами:
2.1 “Качество работы”.
2.2 “Правила непрерывного проектирования”.
2.2 “Совещание по планированию спринта”.
Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
Обеспечивается правилами:
3.1 “Правила планирования проектов”.
3.2 “Совещание по планированию спринта”.
На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
Обеспечивается правилами:
4.1 “Совещание по планированию спринта”.
4.2 Ежедневная работа с представителями бизнеса может быть включена через механизм адаптации процессов “Совещание “Ретроспектива спринта””.
Над проектом должны работать мотивированные личности. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
Обеспечивается правилами:
5.1 “Правила планирования проектов”.
5.2 “Правила запуска проекта”.
5.3 С учетом главного правила назначения работы “люди лучше делают то, что хотят делать”.
Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
Обеспечивается правилами:
6.1 Метод не определяет способа общения внутри команды проекта.
6.2 Есть правила “Правила документирования” и “Правила подготовки и проведения рабочей встречи по проекту” для повышения качества общения.
Работающий продукт — основной показатель прогресса.
Обеспечивается правилами:
7.1 “Правила планирования” проекта определяют все промежуточные цели которые должны быть достигнуты в процессе реализации проекта и их очередность. Каждая достигнутая цель – это готовый к поставке продукт проекта.
7.2. “Правила оценки и планирования задач” совместно с “Совещание по синхронизации команды” исключают “зависание” задач в анализе и проектировании.
Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile-процессы помогают наладить такой устойчивый процесс разработки.
Обеспечивается правилами:
8.1 Все совещания Ритмов.
Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
Обеспечивается правилами:
9.1 Цитата: Качество результата должно быть “превосходным” или “максимально превосходным”.
9.2 “Правила непрерывного проектирования”.
Простота — искусство минимизации лишней работы — крайне необходима.
Обеспечивается правилами:
9.1 “Правила планирования проектов” – снижают количество выполняемой работы и фокусируют на достижении цели.
9.2 “Правила непрерывного проектирования” – обеспечивают поддержку простоты.
Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
Обеспечивается правилами:
11.1 Метод не определяет роли, должности и способы управления командой.
11.2 Все мероприятия Метода построены на демонстрации фактов (метрик) и задавании вопросов на каждом уровне управлении, команда проекта сама принимает решение о способе организации работы.
Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Обеспечивается правилами:
12.1 “Ритм внедрения улучшений”.
О ценностях Манифеста
Люди и взаимодействие выше процессов и инструментов
1.1 Метод базируется на предпосылке “Люди хорошие и действуют из наилучших побуждений”, и второй посылке “Все лгут”. Исходя из них все Ритмы Метода используют метрики и вопросы для повышения качества взаимодействия.
Работающий продукт выше исчерпывающей документации
2.1 Здесь следует определить термин “исчерпывающей” – то есть документации описывающей всё. В адаптации Метода к ИТ-проектам, есть “Правила документирования реализации” которые определяют ту документацию которая нужна для поддержания жизненного цикла программного обеспечения.
Сотрудничество с заказчиком важнее согласования условий контракта
3.1 Метод не рассматривает аспекты согласования условий контракта, но за счёт “Правила запуска проекта” и рекомендаций для Бизнес-аналитиков обеспечивает лучшее попадание в ожидания Заказчика не исключая (а даже поощряя) его вовлечения в процесс разработки программного обеспечения.
Готовность к изменениям важнее следования первоначальному плану
4.1 Метод имеет средства планирования проекта для проектов с известным содержанием, и имеет правила управления проектом с неизвестным содержанием. Если Заказчик готов платить за исследования, и непрерывное изменение вектора развития, то Метод предоставляет правила управления изменениями.
4.2 “Совещание по планированию спринта” определяют детали реагирования на изменения.
4.3. Правила “Принятие решений на основе показателей” определяет цель изменений и повышает качества управления заинтересованными сторонами.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
5.1 Метод определяет Правила удовлетворения потребностей справа и необходимости адаптации к среде способом слева исключая конфликт интересов.
Выводы
Метод управления проектным бизнесом можно считать Agile-подходом, который не только поддерживает и реализует все принципы Манифеста гибкой разработки программного обеспечения но и устраняет конфликт между позицией Заказчика и команды проекта со стороны Подрядчика .
