CC BY
77
УДК 65.012.6 Д.Н. Лопатин
Омский государственный технический университет, г. Омск.
AGILE - НОВЫЙ УРОВЕНЬ МОТИВАЦИИ В МЕНЕДЖМЕНТЕ
Сегодня в теории и практике менеджмента идет борьба по решению фундаментальной головоломки: как соединить строгую дисциплину с непрерывными инновациями? Усиление одного выглядит одновременно как причина ослабления другого. Требование исполнительности и дисциплины убивает инновативность, а инновации по природе своей обратны дисциплине. Проблема кажется нерешаемой. Тем не менее, уже известны некоторые прорывы в данном направлении. Эти прорывы касаются работы команд разработчиков программного обеспечения, которые одновременно достигали большой исполнительности и дисциплины и непрерывных инноваций, что было невозможно при традиционных методах менеджмента. За последнее десятилетие под разными названиями эти практики менеджмента прошли обкатку в тысячах организаций по всему миру.
Специфику данной проблемы определяет то обстоятельство, что эти открытия в сфере менеджмента были сделаны не академиками в бизнес-школах или высокооплачиваемыми менеджерами. Эти открытия были сделаны специалистами по разработке программного обеспечения. В ретроспективе нетрудно понять, почему именно они решили проблему. В 90х годах прошлого столетия огромные суммы были потеряны, потому что разработчики программного обеспечения постоянно запаздывали, редко укладывались в бюджеты, сильно страдало качество ПО. Клиенты были не удовлетворены, компании теряли деньги. Виновниками в этой ситуации выглядели разработчики, их обычно наказывали. Стандартные способы управления персоналом и мотивации не работали с разработчиками ПО. Должно было появится что-то новое и отличное.
Однако к сегодняшнему дню технологии Agile не получили широко обсуждения в теории и практике менеджмента. Единственная книга по менеджменту, которая содержит значительные упоминания Agile, это книга Марка Эддлсона «Превыше управления: взятие ответственности в работе».
Что же можно определить в технологиях Agile, как основное?
Гибкая методология разработки (англ. Agile software development) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки и динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Большинство гибких методологий
31
нацелены на минимизацию рисков, путем сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.
Agile-методы делают упор на непосредственное общение лицом к лицу. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных.
В феврале 2001 в штате Юта (США) был выпущен «Манифест гибкой методологии разработки программного обеспечения» (Agile Manifesto). Данный манифест был одобрен и подписан представителями разных методологий. Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако именно после этого события произошло вхождение Agile-разработки в массы.
Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются успешные команды. Agile Manifesto не содержит практических советов. Его основные идеи таковы:
■ Личности и их взаимодействия важнее, чем процессы и инструменты;
■ Работающее программное обеспечение важнее, чем полная документация;
■ Сотрудничество с заказчиком важнее, чем контрактные обязательства;
■ Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto:
■ удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения;
■ приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
■ частая поставка рабочего программного обеспечения (каждый месяц или неделю или еще чаще);
■ тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
■ проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
■ рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
■ работающее программное обеспечение — лучший измеритель прогресса;
■ спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
■ постоянное внимание улучшению технического мастерства и удобному дизайну;
■ простота — искусство не делать лишней работы;
■ лучшие технические требования, дизайн и архитектура получаются у самоорганизо-ванной команды;
■ постоянная адаптация к изменяющимся обстоятельствам.
Основным критическим замечанием является то, что при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к
32
управлению требованиями не подразумевает далеко идущих планов (по сути, управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы. Это может привести к снижению качества продукта и накоплению дефектов.
Существуют методологии, которые придерживаются ценностей и принципов заявленных в Agile Manifesto:
■ Agile Modeling — набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения. Не включает в себя детальную инструкцию по проектированию. Основная цель: эффективное моделирование и документирование. Но методология не охватывает программирование и тестирование, не включает вопросы управления проектом, развертывания и сопровождения системы. Однако включает в себя проверку модели кодом.
■ Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения для бизнес-приложений.
■ Agile Data Method — группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных
кросс-функциональных команд.
■ DSDM основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). Представляет собой итеративный и инкрементный подход, который придает особое значение продолжительному участию в процессе пользователя/потребителя.
■ Essential Unified Process (EssUP) - основные унифицирующие процессы.
■ Экстремальное программирование (Extreme programming, XP).
■ Feature driven development (FDD) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, используемому в RUP, существенное отличие — это дополнительное ограничение: каждая функция должна допускать реализацию не более, чем за две недели. То есть если сценарий использования достаточно мал, его можно считать функцией. Если же велик, то его надо разбить на несколько относительно независимых функций.
■ Getting Real — итеративный подход без функциональных спецификаций, использующийся для веб-приложений. В данном методе сперва разрабатывается интерфейс программы, а потом ее функциональная часть.
■ OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как легкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов.
■ Scrum устанавливает правила управления процессом разработки и позволяет использовать уже существующие практики кодирования, корректируя требования или внося тактические изменения. Использование этой методологии дает возможность выявлять и устранять отклонения от желаемого результата на более ранних этапах разработки программного продукта.
33
■ Бережливая разработка программного обеспечения (lean software development) использует подходы из концепции бережливого производства.
И хотя методология Agile еще не адаптирована для многих видов деятельности, ее популярность, несомненно, растет.
Библиографический список
1. HRM.RU (ведущий портал о кадровом менеджменте).
2. Addleson, Mark. Beyond management: taking charge at work / Mark Addleson. - New York : Palgrave Macmillan, 2011.
