Поскольку информационные системы являются ядром современного бизнеса, то разработка нового программного обеспечения и поддержка существующего весьма важны для производительности и прибыли. Модернизация технологий программного обеспечения за последние 20 лет позволяла создавать более сложные продукты, предоставляющие компаниям возможность предлагать клиентам новые сервисы и товары. Тем не менее, проекты по разработке ПО до сих пор страдают от всё тех же проблем и характеристик, что и несколько лет назад, независимо от используемых технологий.
Отчет от Standish Group свидетельствует, что надежность предоставления ПО за последние годы не была значительно улучшена. Рисунок 1 отображает результаты за 2001 год, и они очень похожи на диаграмму того же источника за ранние 90-е.
Рис. 1: Проекты по разработке ПО (49% - успешны; 23% - имели препятствия; 28% - потерпели крах)
Важным вопросом является то, почему же разработка ПО настолько рискована?
Изменения неизбежны
Все проекты по разработке ПО имеют свои риски. Одним из основных источников риска являются изменения, происходящие на протяжении жизненного цикла проекта. Наиболее распространенная форма изменений - это изменения пользовательских требований. Однако есть также и другие области, к примеру, следующие изменения все представляют определенный риск для проекта:
- Изменения в команде разработчиков либо участников проекта
- Изменения в используемых технологиях
- Изменения в любых внешних системах, которые должны работать с новой системой
То, как вы справляетесь с изменениями в проекте, является ключом к снижению рисков разработки и увеличению шансов на успешное завершение вашего проекта.
Но какой путь является наилучшим? Основное влияние на данный аспект оказывает выбранный вами процесс разработки, а не используемые технологии.
Выбор правильного процесса
В качестве руководителя проекта вам, скорее всего, захочется попробовать исключить изменения в вашем проекте посредством строгой политики «не производить никаких изменений».
Это как раз пример водопадной модели, которая предполагает, что разработка может продолжаться в линейном и предсказуемом виде. Водопадные процессы имеют четко определенную последовательность этапов, каждый из которых должен быть завершен и одобрен до того, как будет осуществлен переход к следующему этапу.
К примеру, как это показано на рисунке 2, сбор Требований (Requirements) завершается до старта этапа Анализа (Analysis). Планирование продукта (Design) не может быть начато до того, как будет завершен и одобрен этап Анализа (Analysis) и т.д. .
Следующий рисунок отображает типичный жизненный цикл процесса водопадной разработки.
Рис. 2: Водопадная модель разработки
Водопадная модель может на первый взгляд выглядеть достаточно обоснованным подходом. Проблема заключается в том, что разработка зачастую обладает свойством непредсказуемости, а такой подход не может эффективно справиться с грядущими изменениями. В результате такой подход разработки ПО почти всегда
неспособен избежать риска.
Но гораздо хуже то, что с таким типом процесса разработки вы частенько можете испытывать ошибочное чувство спокойствия за то, что проект прогрессирует. Приняв строгую стратегию одобрения по завершении каждого этапа в проекте, очень легко поверить в то, что проект упрощается и уровень риска уменьшается по ходу приближения к сроку выпуска.
Изменения неизбежны на протяжении жизненного цикла, и зачастую эти изменения являются результатом отзывов. Как вы можете заметить на Рис. 3, водопадный процесс разработки предполагает поздний опрос мнений и отзывов в той части, которая наиболее важна, а именно - код самого ПО, а не одобренная документация.
Рис. 3: Работа с изменениями
Как следствие, изменения в системе чаще всего должны быть сделаны
во время последних этапов проекта, таких как интеграция (когда различные модули кода ПО собираются в одну систему приложения) и тестирование системы. Представьте себе, что значит списать проект с трудозатратами в 100 человеко-годов после того, как 95 из них уже были потрачены, - и все из-за существенного недопонимания пользовательских требований!
Профиль риска водопадной модели, отображенный на Рис. 4, не подходит для разработки ПО.
Рис. 4: Водопадный профиль риска
Фундаментальной проблемой водопадной модели является то, что она предполагает предсказуемость прогресса проекта разработки ПО с определенной точностью, а дата завершения может быть надежно вычислена согласно данному предположению. Исходя из того, что цикл разработки будет предсказуем, вы считаете, что высокий риск маловероятен в этом проекте, а это глупо! Водопадный процесс разработки - это неверный подход к разработке ПО.
Итеративная разработка и низкий уровень риска
Риски проекта ассоциируются с чем-то неизвестным. Это могут быть технические, организационные или ориентированные на бизнес риски, например, такие как:
- Как будет наша система общаться с системой A?
- Как мы можем управлять удаленной группой разработчиков?
- Действительно ли требования к системе отображают нужды пользователей?
- И т.д...
Те, кто адаптируют процессы разработки ПО, осознают, что создание ПО - это рискованный бизнес, которому присущ высокий уровень непредсказуемости. Также осознается то, что наилучшим механизмом достижения успешного завершения проекта является контроль и избежание рисков путем регулярного предоставления кода ПО, который можно протестировать. Это предоставит реальную возможность проверять прогресс и отчитываться перед пользователями на протяжении всего жизненного цикла проекта.
Ключевые принципы
Не существует единственно верного правила, которое бы гарантировало успех проекта, но следующие ключевые принципы значительно увеличат ваши шансы в достижении такого результата:
- Принятие итеративного подхода, основанного на риске
- Преданность и вовлеченность высшего руководства
- Высокий уровень общения между всеми членами команды проекта
- Высококвалифицированная команда разработчиков
- Принятие подхода, основанного на сценариях использования (Use Case)
- Принятие комплексной и строгой системы управления изменениями
- Использование визуального моделированя (Visual modelling)
Итеративный подход, основанный на риске
Такой подход поможет снизить уровень риска путем предоставления маленьких частей системы в короткие сроки (максимум 4 недели для больших проектов). В конце каждого цикла разработки ПО должно быть продемонстрировано пользователям и необходимо получить отзывы о функциональности и стабильности.
Итеративный подход будет снижать уровень риска с самого начала. Это происходит потому, что команде необходимо фокусироваться на основной функциональности и находить решения к рискам с высоким уровнем на ранних стадиях разработки.
В качестве реального примера снижения риска при применении такого подхода приведу случай, который произошел в 2001 году, когда я работал над разработкой приложения для мониторинга финансовых транзакций. Одно из пользовательских требований указывало то, что система должна обрабатывать один миллион финансовых операций в восьмичасовом окне. Клиент настаивал на том, что это ключевое требование, и что приложение должно быть способно оперировать на дешевом оборудовании. Мы понимали, что у нас есть большой риск того, что мы не сможет предоставить такую производительность в таких условиях, а потому мы создали рабочую базовую систему в течение трех недель и предоставили пользователям отчет о том, что мы смогли добиться всего 10% от требуемой производительности.
В результате этого пользователи пересмотрели свои цели и поняли, что целесообразнее было бы снизить уровень производительности. Основной риск получилось избежать всего лишь за три недели разработки.
Рисунок 5 предоставляет сравнительный анализ типичных профилей риска итеративной и водопадной моделей разработки. Итеративный цикл постоянно избегает рисков, начиная с ранних этапов, что является результатом постоянных отзывов от пользователей.
Рис. 5: Сравнение профилей риска итеративного и водопадного методов разработки
Преданность и вовлеченность высшего руководства
Наверняка в любом бизнесе сложно изменить то, как люди работают, а если учесть техников, то все еще сложнее. Очень важно иметь полную поддержку для любого изменения процесса. Вам понадобится страховка для того, чтобы выполнить изменения на ранних стадиях, но как только процесс начнет работать, люди естественно захотят быть связанным с ним.
Высокий уровень общения между всеми членами команды
Само собой, основу любого проекта составляют люди - без слаженной работы их всех у вас не будет команды, и ваш проект потерпит крах.
Общение очень важно в среде команды, но гораздо важнее иметь хороший уровень общения с пользователями и спонсорами. Общение должно быть регулярным - каждый день стоит общаться с командой, а с пользователями и спонсорами - хотя бы раз в неделю. Вашей целью должно стать то, чтобы все эти группы людей стали частью общей команды проекта. Итеративная разработка значительно улучшит уровень общения между членами команды.
Общение может быть выражено в разных формах, а не только в вербальной - хорошая документация также может быть использована в качестве средства обмена информацией. Убедитесь в том, что уровень документации соответствующий и записывается только то, что нужно. Для того, чтобы поднять уровень общения, используйте визуальное моделирование (ключевой принцип) при любой возможности.
Высококвалифицированная команда разработчиков
Высококвалифицированная группа людей, которые понимают, как работать вместе, должна составлять ядро вашей команды. Они будут очень эффективны и производительны. Если в вашей команде до сих пор не присутствует хороший набор различных навыков, то вам стоить вложить средства на обучение, нацеленное на реализацию нужд вашего проекта. Тем не менее, не стоит тратить деньги и время на курсы "для всех", а стоит обратить внимание на пополнение вашей команды экспертами для помощи и ускорения выполнения проекта.
Подход, основанный на сценариях (Use Case)
Сценарии использования (Use Cases) очень эффективны, так как они предоставляют контекстное представление требований системы. Одной из основных причин, почему вам стоит их использовать, является то, что они носят нетехнический характер и предоставляют пошаговое описание взаимодействия актеров (пользователей системы - людей или другие системы) с системой. Простота сценариев является их большим преимуществом.
Часто документы, которые должны содержать полное описание требований к системе, на самом деле содержат лишь деловой регламент и список нужд пользователей. Для того, чтобы проект шел вперед, вам необходимо описать все цели и стремления, и для этого более всего подходят сценарии использования. Они связывают весь процесс разработки - от сбора требований пользователей до тестирования программного обеспечения.
Система управление изменениями
Это нечто иное, чем принцип избегания изменений в вашем проекте. Вместо этого, уделите внимание новым запросам и решайте (c пользователями), каким образом данные изменения могут быть реализованы. К примеру, что следует предпринять, если дата завершения строго оговорена, а вам выдвинуто новое требование? Стоит ли вам в таком случае опустить реализацию какого-либо другого требования, или же стоит перенести дату выпуска системы?
Визуальное моделирование ("картина стоит 1000 слов")
Визуальное моделирование - это современное название для блок-схем, используемых раньше в производстве ПО. До сих пор визуальная поддержка очень ценится, и диаграммы должны быть использованы на протяжении всего проекта. Вам стоит требовать от всех использование одной определенной системы обозначений, как от бизнес-аналитиков, так и от дизайнеров, программистов и тестеров. UML - универсальный язык моделирования - является де-факто стандартом разработки систем и должен быть использован для постоянного и четкого общения на протяжении всего проекта. Его использование является безоговорочным условием.
Насколько вы фокусируетесь на рисках?
Я работал со многими клиентами, различным высшим руководством и техническими специалистами, которые клялись в том, что они учитывают все риски и следуют итеративному подходу к разработке ПО. И вы, скорее всего, столкнетесь с этим, но вот как вам узнать, действительно ли ваша группа ИТ-специалистов использует итеративный способ разработки, учитывающий риски?
Вот несколько вопросов, которые помогут вам в этом:
Как долго длится одна итерация?
Правильный ответ - несколько дней либо максимум примерно 4 недели. Ответ «три месяца и более» говорит о том, что процесс до сих пор имеет вид водопадной модели, которая отличается длинными циклами и связана с большим риском пойти по неверному пути, с большой вероятностью обнаружения этого факта в самом конце, когда ситуацию практически невозможно исправить.
Что является результатом каждой итерации?
Ответом должна быть демонстрация пользователям какого- либо рабочего программного обеспечения, с получением при этом от них отзывов и мнений. Если ответом является документ с одобрением, то они не понимают сути метода.
Когда пользователи увидят то, что они должны получить в итоге?
Верным ответом на этот вопрос будет – «в конце каждой (короткой) итерации», а ответ "только во время тестирования перед выпуском" совершенно неприемлем.
Когда вы начнете тестирование интеграции?
Ответом должно быть то, что тестирование интеграции - это продолжительный процесс, который происходит во время каждой итерации.
Как вы управляете рисками?
Должны присутствовать регулярная оценка риска, представленная в виде вероятности и влияния на график разработки, а также предлагаемые стратегии избегания риска. Руководитель проекта должен иметь список возможных рисков, который доступен всех людям, связанным с проектом. Таков примерный ответ на данный вопрос.
Длительная непрерывность бизнес-процессов
Что же получит ваш бизнес в результате использования всего вышеописанного опыта?
Мы знаем, что разработка ПО - это очень рискованный бизнес, который требует много времени, денег и усилий. Но самые большие затраты следуют по завершении начальной разработки, как это показано на рисунке 6, когда система входит в этап поддержки и пересмотра.
Рис. 6: Структура расходов ПО
Переняв этот опыт и фокусируясь на разработке ПО, предоставляющего клиентам то, что им нужно, можно создавать высококачественные системы, наиболее подходящие бизнесу. Такие системы легче поддерживать и модифицировать, что тем самым может снизить последующие эксплуатационные расходы и вероятность рисков.
Cliff Murphy