Универсальность и области применения Agile
В статье будет рассмотрена тема Agile framework. Будет рассмотрено понятие Agile, как оно применяется, является ли оно универсальным и где его уместно применять. Каждый год миллионы американских долларов теряются из-за неудачных проектов информационных систем. В ходе эволюционного развития ИТ, процесса обучения, совершенствования методов, инструментов и навыков, показатели успешности проектов увеличиваются. По мере увеличения объема новых знаний показатели успешности проектов будут продолжать улучшаться (Guidry et al., 2018). Для управления проектами можно выделить классический и Agile-подход. В классическом водопадном варианте есть набор последовательных фаз, которые стекают, как поток воды. Более современная Agile-модель создания программного обеспечения характеризуется итеративным подходом к разработке.
Важность Agile
Когда Agile наделал много шума, по нему было много вопросов, но его появление было органично для эволюционной направленности человеческого взаимодействия в ИТ-проектах. В дальнейшем описании ниже будет использован термин Agile как общий, но наиболее применимым к ИТ-проектам является Scrum. Основываясь Agile подходах, можно сделать следующие утверждения:
- Термин «Agile» — это общий зонтик, под которым собраны различные методы подходов к реализации ИТ-проектов.
- Agile не является полной методологией, Agile включает в себя независимые методы, подходы и фреймворки, прежде всего известные как Scrum, eXtreme Programming (XP), Lean и другие.
- Agile не заменяет другие методы, он не универсален и подходит не для каждого проекта. Agile эффективен в сложных проектах, которые раньше никто не делал, где нет экспертов и лучших практик.
- В Agile документация по-прежнему важна, чтобы не накапливался технический долг, но основное внимание уделяется общению, людям и командной работе.
- В Agile очень важна командная работа по обработке и анализу данных, которые будут формировать гипотезы, которые помогут измерить прогресс от текущего состояния до конечного состояния (Baker & Henderson, 2017). Это требует, чтобы процесс был гибким, целенаправленным и актуальным. После общего описания стоит рассмотреть более подробно, где может применяться понятие. Например, Agile не подходит и может даже навредить при строительстве нового стадиона, но будет эффективен в каком-нибудь экстраординарном проекте вроде интеграции китайского банка, криптовалютного приложения и дата-центра на Южном полюсе, который использует энергия гейзера.
Сравнение жизненного цикла разработки
Как и в любой новинке, здесь есть и противоположные стороны. Виджен и Ван (2009) утверждают, что представители ИТ-культуры рассматривают Agile и плановые методы разработки программного обеспечения как полярные противоположности. При описании жизненного цикла разработки важно отметить следующие моменты:
- Модель водопада включает в себя набор последовательных фаз, которые текут вверх, как вода. Каскадная модель имеет определенные границы и обязанности заинтересованных сторон и состоит из последовательных фаз, в результате которых все шаги становятся входными данными для следующих фаз. Обычно в водопадной модели тестирование может начаться только после завершения кодирования. Если дефекты обнаружены, предыдущие шаги должны быть пересмотрены, чтобы исправить их. Этот процесс является причиной того, что проект выполняется с превышением сроков и бюджета.
Более современная модель гибкой разработки программного обеспечения, которая позволяет использовать поэтапный и итеративный подход к разработке программного обеспечения, требует полной интеграции тестирования с разработкой (Янг и др., 2011). Потребность пользователей заключается в своевременном выпуске качественного программного обеспечения. Таким образом, высококачественное программное обеспечение должно производиться меняющиеся потребности потребителей. И разработка экспериментального программного обеспечения, экстремальное программирование (XP) является наиболее известным методом, позволяющим создавать высококачественное программное обеспечение.
Примеры проектов
Далее будут представлены различные примеры, которым может следовать руководитель проекта, столкнувшись с неудачным проектом информационных систем. При целостном рассмотрении стратегическая основа для принятия управленческих решений может быть интегрирована. Независимо от Agile или классического подхода, для проекта остаются важными три показателя: деньги, время и объем. В своем исследовании Guidry et al (2018) приводят следующие примеры проектов, на которые стоит обратить внимание:
Функциональность
Пример, когда часть программы не позволяет реализовать полный функционал и программа бесполезна для заказчика. Компания Carolina Ingredients начала использовать ручные сканирующие устройства на всех производственных предприятиях в 2012 году для облегчения ввода данных. Было обнаружено, что на момент покупки система работала не так, как планировалось. Во время первоначальной установки программное обеспечение было только что выпущено и еще не содержало модуля, позволяющего программному обеспечению сканера обмениваться данными. Примерно через три месяца этот модуль был доставлен. Однако установка показала, что модуль не работает должным образом. Спустя полгода после первоначальной установки программа наконец-то заработала должным образом.
Бюджет и время увеличиваются в проекте CityTime.
Проект был начат в 1998 году городом Нью-Йорком. К 2011 году стоимость проекта достигла почти 700 миллионов долларов при первоначальном бюджете в 63 миллиона долларов. В ходе проверки было установлено, что проект с самого начала реализовывался ненадлежащим образом, что привело к значительному росту цен. Аудит пришел к выводу, что невозможно количественно оценить последствия бесхозяйственности.
Сокращение масштабов
Примером сокращения масштабов является проект Калифорнийского департамента транспортных средств. Первоначально проект был создан в 2006 году для пересмотра действующего метода регистрации транспортных средств и выдачи лицензий перевозчиков. По состоянию на февраль 2013 года, спустя семь лет с момента начала проекта, было потрачено 208 миллионов долларов. Затем государственные чиновники решили свернуть проект. Из-за отложенных сроков и отсутствия прогресса они решили отказаться от модуля регистрации транспортных средств, и официальные лица в настоящее время не уверены в общей стоимости и функциональности проекта.
Слабые стороны Agile
Несмотря на все его инновации и сильные стороны, слабые стороны Agile проявляются совсем в другой среде. Ниже приведены мои собственные утверждения как сертифицированного скрам-мастера:
- Чтобы получить все преимущества Agile, организация должна использовать Aglie в полном объеме. Нельзя взять просто часть Agile и сказать, что организация теперь Agile. Если компания внедрила только ежедневные встречи и забросила все остальное, это не Agile.
- Нет смысла применять Agile для строительства здания или другого классического водопадного проекта.
- Agile не будет работать, если заказчик не может или не хочет быть вовлеченным в процесс.
- Невозможно избежать документации и планирования. Как ни парадоксально, в Agile нужно разрабатывать необходимую документацию и планировать работу.
- Agile успешен в профессиональной, мотивированной и самоорганизованной команде.
- Agile требует фундаментального отхода от философии управления и контроля традиционных иерархических бюрократических организаций.
В заключение можно констатировать, что использование Agile-методов для разработки информационных систем более эффективно, чем классический водопадный метод, в силу его эволюционных особенностей. Однако использование Agile обусловлено спецификой этого метода и применимо не ко всем проектам. Agile — мощный и высокоэффективный инструмент, но он эффективно работает только в определенных ограниченных средах.
Ссылки
Бейкер, Бейкер, Дж. В., и Хендерсон, С (2017). Процесс науки о киберданных. Обзор киберзащиты, 2(2), 47–68.
Гидри, Т.Л., Халлиган, Б.Б., и Питерс, К (2018). Стратегии обработки сбоев в разработке информационных систем. Журнал управленческих вопросов, 30 (3), 363–377.
Видген, Р., и Ван, X (2009). Совместно развивающиеся системы и организация гибкой разработки программного обеспечения. Исследования информационных систем: ISR, 20 (3), 355–376.
Ян, Онита, Чжан и Даливал (2011). TESTQUAL: Концептуализация тестирования программного обеспечения как услуги. Журнал электронных услуг, 7(2), 46.
