CC BY
20
УДК 005.1
Симанов М.Д.
студент Бородин Г.А. студент 3 курса факультет ФМЭСИ научный руководитель: Староверова О.В., д.ю.н.
доцент
кафедра «Управления информационными системами и программирования» РЭУ им. Г.В. Плеханова Российская Федерация, г. Москва AGILE ПО-РУССКИ Аннотация. В статье рассматривается опыт самостоятельного внедрения компаниями Agile-методологий и последующая работа по этим принципам в России. Рассмотрены основные плюсы и минусы по сравнению с главным конкурентом - Waterfall model. Также приводятся особенности адаптации Agile и понимание гибких методологий разработок российскими компаниями без наличия консультантов, опыта в виде предыдущих практик, что приводит к «Agile по-русски».
Ключевые слова: гибкие методологии разработки, Agile, Waterfall, Scrum, внедрение, подмена понятий.
Simanov M.D., student Borodin G.A., student 3nd year, FMESI Plekhanov Russian University of Economics Research superviser: Staroverova O.V., doctor of law Associate Professor of the Department of Information Systems Management
and Programming Plekhanov Russian University of Economics Annotation: The article considers the experience of independent implementation by companies of Agile-methodologies and the subsequent work on these principles in Russia. The main pluses and minuses are compared with the main competitor - Waterfall model. Also, the specifics of adaptation of Agile and the understanding of Agile software development by Russian companies without the presence of consultants, experience in the form of previous practices, which leads to "Agile in Russian."
Key words: Agile software development, Agile, Waterfall, Scrum, implementation, substitution of concepts.
Совершим путешествие в 1883 год, штат Небраска, США. Эпоха колонизации Дикого Запада была аллюзией на первобытных людей, которые познавали дикий новый мир лишь своими усилиями при жесткой ограниченности материалов и времени. Свои жилища они строили поэтапно, начиная с маленького жилища из дерна и модернизируя их год за годом до капитальных построек.
Теперь вернемся в 2001 год, штат Юта, США. 17 человек выпустили «Манифест гибкой методологии разработки программного обеспечения». Спустя годы этот манифест стал некой Библией для многих разработчиков ПО по всему миру, ведь до сих пор не существовало никакой альтернативы золотому стандарту в виде Waterfallили методом водопада. Если попытаться донести суть А§Иедо «простого люда», то представьте, что у вас есть футбольное поле, которое ограниченно боковыми линиями, но внутри ты можешь действовать как захочешь. Эти границы футбольного поля и сформулированы в AgileManifesto.
Для дальнейшего разбора и адаптации в сознании основных концепций, поэтапно рассмотрим их:
1. Технические и бизнес-подразделения совместно располагаются в открытой зоне.
Первые а§Ие-последователи начинали с ключевых сотрудников (менеджер проектов, системные и бизнес-аналитики, разработчики, тестировщики), но со временем процесс охватил всех работников. Например, с технологической стороны сегодня широко распространена практика объединения инженеров по анализу и обработке данных, администраторов баз данных и персонала по технологическим операциям в одном подразделении, даже если они находятся там всего лишь временно.
2. Сценарии тестирования разрабатываются до начала этапа программирования.
В случае разработки на основе тестов разработчикам предоставляется возможность сразу проверить работоспособность своего кода. Несмотря на тот факт, что в реальности многие команды пытаются реализовать этот шаг до начала этапа программирования, самое важное - это составление сценариев тестирования, особенно сценариев модульного тестирования, которые часто не используются вообще в каскадной модели.
3. Утренние планерки проводятся каждый день.
В ходе таких планерок команда собирается в круг и каждый участник рассказывает о том, что он сделал вчера, что планирует сделать сегодня, и с какими проблемами он столкнулся. Все вопросы, требующие больше времени, чем краткое обсуждение, документируются и рассматриваются позже. При
этом, очень важно чтобы все стояли, так как это подчеркивает необходимость быть кратким.
4. Процесс состоит из рабочих циклов продолжительностью от одной до четырех недель, которые называют «спринтами».
На выходе каждого цикла получается рабочий код. Исходя из опыта, можно сказать, что двухнедельные спринты обеспечивают сбалансированную возможность создать что-то действительно ценное при сохранении чувства срочности. Каждый цикл включает в себя:
• «Игровое планирование»,
• Разработку макетов экранов и тестовых сценариев.
• Написание кода и тестирование взаимодействия компонентов системы.
• Демонстрацию рабочего кода рабочей группе и руководству технического или бизнес-подразделения.
• Ретроспективное обсуждение того, что в рамках цикла прошло хорошо, а что следует изменить в будущем.
Распределенная гибкая модель
Большинство организаций не могут позволить себе роскошь собрать всех разработчиков в одном физическом месте, поэтому сомневаются, подойдет ли им а§Ие-модель. Она подойдет, но это потребует инвестиций в технологии и командировки.
Плюсы методологий:
Гибкая модель
• Корректировки функциональных требований встроены в процесс разработки для обеспечения конкурентного преимущества. По сути, уже через 2 итерации проект можно развернуть на 360 градусов и делать совсем другой продукт.
• Проект разделен на короткие и прозрачные итерации.
• Минимизация рисков благодаря гибкому процессу внесения изменений.
• Быстрое получение первой рабочей версии продукта.
Каскадная модель
• Понятная и простая структура процессов, удобная для команд с небольшим опытом.
• Качественная и детальная документация.
• В проекте можно легко отследить ресурсы, риски и затраченное время.
• Задачи продукта стабильны от начала до конца.
Минусы методологий:
Гибкая модель
• Невозможно подсчитать точную сумму работы из-за постоянно меняющихся требований.
• Поскольку Agile скорее философия, чем процесс, в систему нужно погрузиться и принять её, что требуется не каждому проекту.
• Команда должна быть высококвалифицированной и опытной, ориентированной на клиента.
• Новые требования могут противоречить существующей архитектуре или функционалу.
• Со всеми корректировками и изменениями есть риск, что проект не закончится никогда.
Каскадная модель
• Требования определяются и закрепляются в самом начале, что лишает процесс разработки гибкости.
• На проект тратится большее количество времени и ресурсов.
• Клиент увидит только готовый продукт, изменить что-либо крайне сложно.
• Отсутствие обратных связей между этапами разработки.
Гибкая модель разработки действует, если:
1. В проекте задействована опытная команда.
2. Окончательный функционал продукта пока неизвестен, и изменения необходимо вносить максимально оперативно.
3. Конечный пользователь «варится» в проекте с самого начала.
4. Необходимо быстро разработать рабочее ПО.
5. Вы стартап.
Выбирайте каскадную модель в случаях, если:
1. Требования к проекту стабильны и практически неизменны;
2. Качество продукта намного важнее затраченного времени и ресурсов;
3. Проект разрабатывается на аутсорсе;
4. Конечный пользователь только принимает результат работы, не участвуя в процессе.
Нет смысла использовать Agile, когда клиент должен работать по четкому бюджету или графику. Следует также избегать гибкого подхода, если клиенты не смогут изменить объем и содержание проекта, как только он стартовал.
Agile с точки зрения заказчика
Несмотря на то, что идея применимости Agile во всех проектах часто звучит, нужно давать себе отчёт в том, что применение подходов Agile всё же ограничено различными условиями. В первую очередь внимание на подобные условия следует обратить заказчику, преследующему цель максимальной эффективности своих инвестиций. В таком случае следует обратить внимание
на ряд условий:
1. Agile, являясь гибкой моделью, приветствует изменения условий даже на поздних стадиях проектирования, однако, во многих случаях подобные изменения могут повлечь за собой серьёзные увеличения затрат на реализацию. Для крупных проектов минимизация вероятности внесения изменений на поздних этапах жизненного цикла проекта часто является одним из главных условий, а сама философия Agile противоречит достижению подобной цели.
2. В случае, когда деятельность имеет чёткое направление, Agile также не имеет смысла использовать. Например, при постройке здания невозможно запустить непосредственно строительство без готового проекта, причём, изменение решений архитектора зачастую просто невозможно.
3. В подавляющем большинстве Agile-проектов команда, ответственная за разработку, работает с итерацией проекта только до её окончания, что усложняет процессы поддержки и внедрения крупномасштабных решений.
4. Методология Agile поощряет приоритезацию составляющих проекта. Если заказчик ставит целью реализацию всех задач в минимальные выполнимые сроки, применение Agile является невозможным.
5. Agile предполагает постоянную вовлечённость заказчика на всех этапах реализации проекта, однако, приём результатов предполагается на последних итерациях. В случае, если заказчик хочет внедрить систему поэтапного приёма, Agile не подойдёт, так как методология подразумевает возможность внесения изменений на всех этапах.
Если подытожить, то главное слово - Software. Так думали создатели. Но вот парадокс - в России 93,6% компаний, использующих Agile в проектах, понимают его как метод ведения проектной деятельности и способ организации свободной и дружелюбной обстановки для сотрудников.
Причем 77% из них занимаются совсем не разработкой программного обеспечения. И этот процент будет неуклонно расти, ведь по тем же опросам в ближайшие два года точно не будет развивать у себя Agile лишь 9% респондентов.
Рисунок 1 - результаты ежегодного опроса компаний от VersionOne В целом, Agile является далеко не настолько простой методологией, как многие утверждают, и зачастую его применение является просто невозможным. Однако, многие практики, относящиеся к данной методологии, являются крайне эффективными, поэтому при управлении проектом следует оценить возможность их применимости и не пренебрегать их использованием, хотя в таком случае проект и нельзя будет отнести к реализованным полностью в соответствии с методологией Agile.
В России Agile набирает стремительную популярность, однако, основной проблемой остаётся нехватка компетентных кадров. Мы считаем, что для исправления подобной ситуации необходимо вводить дисциплины, изучающие гибкие модели разработки, в систему высшего образования, причём, не только на IT-специальностях, но и на управленческих.
Использованные источники:
1. James A. Highsmith. Agile Software Development Ecosystems. - Addison-Wesley Professional - 2002 - P. 55 - 58
2. When Agile Can't Be Used on Projects [Электронный ресурс] URL: https://www.pmis-consulting.com/when-agile-cant-be-used-on-projects/ (дата обращения 10.11.2017г.)
3. Manifesto for Agile Software Development [Электронный ресурс] URL: http://agilemanifesto.org (дата обращения 9.11.2017г.)
4. State of Agile Report [Электронный ресурс] URL: https://www.pmis-consulting.com/when-agile-cant-be-used-on-projects/ (дата обращения 15.11.2017г.)
