Суперсеты, эстафеты и гонки на скоростных спорткарах – спортивный agile подход к процессу выполнения проекта
Основное отличие методологии agile от прошлых методов разработки состоит в понимании того, что в ходе проекта все может изменяться. Поэтому важно и нужно учитывать эти изменения, чтобы результат проекта наиболее полно удовлетворял его бизнес-цели и выполнял поставленные задачи. О самых популярных гибких методологиях разработки и опыте их применения в рубрике TADетали рассказали эксперты ГКС (АО «Группа Систематика»).
Содержание |
В процессе реализации всего многообразия проектов ГКС внедряет разные классы информационных систем: с разной функциональностью (ERP, CRM, ECM и др.), направленные на все категории пользователей: от клиентов, партнеров до топ-менеджеров и сотрудников функциональных подразделений.
В рамках всех этих внедрений применяются элементы философии agile. Эта философия сформировала класс методологий управления проектами, который включает в себя: Scrum, Kanban, XP (eXtreme Programming), Lean, FDD (Feature Driven Development) и другие.
Ключевые характеристики философии agile сформулированы в манифесте:
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Основной недостаток прежнего каскадного подхода к управлению проектами в том, что нельзя объять необъятное и изначально проанализировать и описать задачу так идеально и подробно, чтобы в ходе проекта не было изменений, и в конце получился нужный результат. Какие-то детали зачастую проясняются только в процессе работы над проектом. К этому добавляются возможные неточности при передаче информации между людьми. Ошибка, которую сложнее всего исправить – это ошибка на стадии постановки задачи, когда приходится переделывать работу.
Scrum
Одна из самых популярных гибких методологий – это Scrum. В ней работа разделена на четкие короткие циклы, которые не рекомендуется увеличивать по длительности. Проектная команда проходит точно по циклу, при этом она работает единой командой с заказчиком. В начале каждого цикла ставится задача, по его окончании результаты представляются и обсуждаются с ним. Фактически заказчик принимает непосредственное участие в проектной команде в ходе разработки. На следующий цикл ставится новая задача или уточняется текущая, если требования изменились. Таким образом, работа выполняется методом прототипирования путем постепенного приближения к итоговому результату проекта.
Хотя методология Scrum и называется гибкой по подходу к достижению конечного результата, при ее использовании правила работы достаточно жестко регламентированы, в том числе цикличность, длительность циклов, совместное участие в проектной команде заказчика и исполнителя, организация процесса работы команды.Российский рынок видеоконференцсвязи: оценки, драйверы, крупнейшие участники. Обзор TAdviser
Можно сравнить Scrum с фитнес-тренировкой, организованной по принципу суперсетов. Упражнения в такой тренировке выполняются в жесткой связке друг с другом с четко фиксированным количеством повторений и промежутками отдыха между подходами, что помогает добиться желаемого результата в срок.
Важным отличием Scrum от традиционной методологии управления проектами является то, что в классической схеме изначально проводится детальное обследование и анализ требований заказчика, формируется и утверждается ТЗ, работа по которому происходит в дальнейшем без отклонений. При применении гибких методологий анализ и уточнение требований не прекращается до получения конечного результата, а изначальный вектор развития может меняться по ходу проекта.
Другим отличием является то, что команда всегда работает совместно с заказчиком, он не оторван от проекта, а активно вовлечен во все происходящие в проекте процессы.
Еще одно важное отличие – прозрачность процесса работы над проектом. Заказчик видит промежуточные результаты по окончании каждого рабочего цикла, имеет возможность внести изменения до финального релиза. В традиционной методологии результат разработки представляется заказчику только в конце проекта и, если он недоволен, работу приходится переделывать.
Kanban
Еще одна из популярных гибких методологий – Kanban. В ней используется панель для визуализации, на которой карточками наглядно отмечаются текущие задачи и стадии их выполнения. Все стадии производства разделены на колонки: «к выполнению», «в процессе», «на проверке», «сделано», а специалисты отмечают, на какой стадии находится каждая задача, и последовательно передают ее дальше.
Основная идея методологии Kanban: каждая задача должна быть как можно быстрее выполнена. Статус выполнения задач регулярно отслеживается, и если что-то «зависло» на одной стадии, ресурсы команды перебрасываются на этот участок, чтобы сдвинуть процесс выполнения задачи дальше и завершить ее как можно быстрее.
Методику Kanban можно сравнить с эстафетой: каждый спортсмен-участник эстафеты стремится выполнить свой этап как можно быстрее и вовремя передать эстафету на следующий этап.
XP (eXtreme Programming)
Эффективным способом интенсивной работы над проектом является метод XP (eXtreme Programming), во многих вариациях которого за одним рабочим местом находятся два специалиста. Например, разработчик пишет код, а заказчик тут же проверяет полученный результат.
XP можно сравнить с автомобильными гонками, когда автомобилем управляют водитель и штурман.
ГКС часто выполняет сложные масштабные проекты, в которых невозможно предусмотреть все тонкости и детали в самом начале и указать в ТЗ. Необходимость применения гибких подходов к выполнению таких проектов очевидна. Эксперты ГКС по продажам комплексных проектов стремятся добиться того, чтобы результат был полезным, работоспособным, удовлетворял требования заказчика, а созданные ГКС системы долго и эффективно использовались. Это особенно важно в проектах заказной разработки информационных систем, в которых в каждом случае создается новый уникальный программный продукт, которого не существовало ранее, а уточнения задачи появляются по ходу проекта.
При работе над проектами с помощью гибкой модели разработки, когда направление развития уточняется по ходу, может возникнуть вопрос: как отслеживать статус исполнения проекта? В отличие от каскадной модели, где работа идет поэтапно, и стоящие задачи выполняются последовательно, а значит, можно оценить, сколько их, и какая часть проекта реализована, при гибкой разработке – это открытый вопрос.
Для его решения руководителями проектов ГКС используется специальная форма отчета о статусе проекта, которая содержит актуальный перечень реализуемых функций системы и документов и стадии их реализации и позволяет заказчику отслеживать статус реализации проекта.
Используя элементы метода Kanban, совместная команда ГКС, состоящая из исполнителя и заказчика, отмечает постадийно, что сделано, готов ли документ, реализована ли функция, протестирована ли она и установлена на продуктивную среду.
Примеры
Рассмотрим примеры, иллюстрирующие применение гибких методологий в проектах ГКС.
Проект 1. Личный кабинет клиента для энергокомпании
В ГКС обратился заказчик из энергетической отрасли, которому требовался личный кабинет клиента. Главная цель проекта: клиент может подключиться к электрическим сетям без прихода в офис энергетической компании.
В начале проекта было концептуально задано направление работ, а также существовал отраслевой стандарт, какие функции должны быть реализованы в личном кабинете клиента такой компании. Проект выполнялся совместной творческой командой с заказчиком. Особое внимание было уделено разработке дизайна и проектированию удобного и понятного для клиентов компании пользовательского интерфейса системы.
Совместная проектная команда регулярно собиралась, обсуждала какой должна быть будущая система, по результатам обсуждения готовились макеты интерфейса и демонстрировался динамический прототип системы, затем он снова обсуждался, корректировался и снова демонстрировался проектной команде. Несколько раз концепция интерфейса перерабатывалась. В результате итеративно была разработана система, которая устроила заказчика и понравилась клиентам.
Благодаря особенностям гибкого подхода в ходе разработки системы были придуманы визарды – динамические инструкции, наглядно объясняющие клиенту, что делать и куда обращаться в его ситуации. При составлении инструкций опирались на часто задаваемые вопросы, с которыми клиенты обращаются в компанию. Целью было доходчиво, понятным клиенту языком объяснить, как пройти нужную ему процедуру.
Заказчик был особенно заинтересован в реализации этого проекта в связи с тем, что Россия участвует в мировом рейтинге инвестиционной привлекательности Doing Business, где одним из критериев оценки является доступность энергетической инфраструктуры для предпринимателей. Успешная реализация данного проекта и запуск системы в эксплуатацию в совокупности со многими другими проектами позволили повысить рейтинг инвестиционной привлекательности России среди других стран мира.
Проект 2. Корпоративная система для страховой компании
Перед экспертами ГКС была поставлена задача разработки корпоративной учетной системы по индивидуальным требованиям страховой компании. Работа велась вместе с заказчиком. Он принимал непосредственное участие в определении бизнес-требований, тестировании, внедрении результатов на продуктивную среду и подготовке персонала для работы с системой.
В проекте активно использовались элементы подхода Kanban. Все задачи велись в системе учета и управления, каждая из задач проходила все необходимые стадии: инициация, формирование бизнес-требований, определение приоритета и включение в план разработки, анализ и разработка функциональных требований, проектирование, разработка, тестирование, установка на продуктивную среду и внедрение.
Каждая такая задача рассматривалась как мини-проект, который участники команды стремились провести от начала до конца как можно быстрее, в соответствии с приоритетом задачи. Руководством проекта проводился мониторинг, сколько задач находилось на каждой из стадий: постановка, разработка, тестирование. Если возникала перегрузка по постановке, туда добавлялись дополнительные ресурсы аналитиков заказчика или исполнителя, если по разработке – перераспределялись ресурсы разработчиков. Работа организовалась так, чтобы бизнес-пользователи как можно раньше могли получить требуемый результат.
Проект 3. Система проектного документооборота для энергетической компании
В этом проекте система создавалась путем поэтапного прототипирования и демонстрации промежуточных результатов ключевым пользователям заказчика. Документирование системы выполнялось параллельно по результатам демонстраций рабочего прототипа системы.
Задачей проекта было создать удобную электронную систему управления техническим проектным документооборотом в компании и внедрить регламент электронного согласования проектной документации. До этого весь технический проектный документооборот в компании был бумажным, что было крайне неудобно. Это задерживало на месяцы процесс согласования, так как были задействованы сотрудники многих филиалов компании, и соответственно возможность начала строительства объектов, которых ждали потребители. Также повышался риск потери документов.
Система, разработанная ГКС, позволила перевести процесс документооборота в электронный вид и проводить согласование намного быстрее, в параллельном режиме согласовывать сложные технические документы по разделам в соответствии с матрицей ответственности подразделений. В результате у заказчика появилась возможность проводить согласование большего объема проектной документации в сжатые сроки, максимально распараллелить работу путем одновременного подключения к системе технических экспертов территориально-распределенных подразделений и филиалов компании. Также в ходе проекта был создан электронный архив проектной документации с удобным удаленным доступом для всех заинтересованных подразделений.
Выбранная в проекте программная платформа Documentum xCP позволила оперативно подготовить рабочий прототип системы на ранней стадии проекта и продемонстрировать его ключевым пользователям, вошедшим в рабочую группу проекта со стороны заказчика. Все пожелания и замечания пользователей сразу вносились и в ТЗ, и в рабочий прототип системы. Далее переходили к обсуждению и реализации следующего модуля системы.
Фактически рабочая система появилась одновременно с проектной документацией на нее. Таким образом, последовательная доработка прототипа системы позволила реализовать итоговый результат, устраивающий заказчика.
Дополнительным преимуществом такого подхода к проекту явилось то, что ключевым пользователям заказчика не потребовалось читать большой объем сложной технической проектной документации и пытаться визуализировать для себя предлагаемые в ней ИТ-решения. Получаемый результат в виде рабочего прототипа информационной системы можно было сразу смотреть и давать к нему свои предложения и замечания. Как результат, в кратчайшие сроки удалось получить готовую устраивающую заказчика систему, ввести ее в эксплуатацию и подключить пользователей.
Влияние agile-методологий на стоимость и сроки выполнения проекта для заказчика
По мнению экспертов ГКС по продажам комплексных продуктов, стоимость и сроки проекта при его реализации с использованием agile-методологий становятся оптимальными, так как оценка реализуемых в проекте задач производится в тот момент, когда каждая задача становится максимально ясна и актуальна. Все заинтересованные стороны понимают необходимость ее реализации и требования, при этом определены подход к реализации и необходимые ресурсы.
Подход позволяет выполнить задачу в рамках ограничений бюджета и точно к требуемому сроку, так как исполнители берутся не за глобальную масштабную долгосрочную задачу, а реализуют точно то, что в данный момент требуется заказчику.
Смотрите также
- Agile software development
- Agile в управлении государственными проектами
- Scrum
- DevOps Методология
- Канбан (Kanban)
- Lean
45