Снижение уровня рисков и увеличение вероятности успеха проекта - Итеративный подход, основанный на риске

Итеративный подход, основанный на риске

Такой подход поможет снизить уровень риска путем предоставления маленьких частей системы в короткие сроки (максимум 4 недели для больших проектов). В конце каждого цикла разработки ПО должно быть продемонстрировано пользователям и необходимо получить отзывы о функциональности и стабильности.

Итеративный подход будет снижать уровень риска с самого начала. Это происходит потому, что команде необходимо фокусироваться на основной функциональности и находить решения к рискам с высоким уровнем на ранних стадиях разработки.

В качестве реального примера снижения риска при применении такого подхода приведу случай, который произошел в 2001 году, когда я работал над разработкой приложения для мониторинга финансовых транзакций. Одно из пользовательских требований указывало то, что система должна обрабатывать один миллион финансовых операций в восьмичасовом окне. Клиент настаивал на том, что это ключевое требование, и что приложение должно быть способно оперировать на дешевом оборудовании. Мы понимали, что у нас есть большой риск того, что мы не сможет предоставить такую производительность в таких условиях, а потому мы создали рабочую базовую систему в течение трех недель и предоставили пользователям отчет  о том, что мы смогли добиться всего 10% от требуемой производительности.

В результате этого пользователи пересмотрели свои цели и поняли, что  целесообразнее было бы снизить уровень производительности. Основной риск получилось избежать всего лишь за три недели разработки.

Рисунок 5 предоставляет сравнительный анализ типичных профилей риска итеративной и водопадной моделей разработки. Итеративный цикл постоянно избегает рисков, начиная с ранних этапов, что является результатом постоянных отзывов от пользователей.

Рис. 5: Сравнение профилей риска итеративного и водопадного методов разработки

Преданность и вовлеченность высшего руководства

Наверняка в любом бизнесе сложно изменить то, как люди работают, а если учесть техников, то все еще сложнее. Очень важно иметь полную поддержку для любого изменения процесса. Вам понадобится страховка для того, чтобы выполнить изменения на ранних стадиях, но как только процесс начнет работать, люди естественно захотят быть связанным с ним.

Высокий уровень общения между всеми членами команды

Само собой, основу любого проекта составляют люди - без слаженной работы их всех у вас не будет команды, и ваш проект потерпит крах.

Общение очень важно в среде команды, но гораздо важнее иметь хороший уровень общения с пользователями и спонсорами. Общение должно быть регулярным - каждый день стоит общаться с командой, а с пользователями и спонсорами - хотя бы раз в неделю. Вашей целью должно  стать то,  чтобы все эти группы людей стали частью общей команды проекта. Итеративная разработка значительно улучшит уровень общения между членами команды.

Общение может быть выражено  в разных формах, а не только в вербальной - хорошая документация также может быть использована в качестве средства обмена информацией. Убедитесь в том, что уровень документации соответствующий и записывается только то, что нужно. Для того, чтобы поднять уровень общения, используйте визуальное моделирование (ключевой принцип) при любой возможности.

Высококвалифицированная команда разработчиков

Высококвалифицированная группа людей, которые понимают, как работать вместе, должна составлять ядро вашей команды. Они будут очень эффективны и производительны. Если в вашей команде до сих пор не присутствует хороший набор различных навыков, то вам стоить вложить средства на обучение, нацеленное на реализацию нужд вашего проекта. Тем не менее, не стоит тратить деньги и время на курсы "для всех", а стоит обратить внимание на пополнение вашей команды экспертами для помощи и ускорения выполнения проекта.

Подход, основанный на сценариях (Use Case)

Сценарии использования (Use Cases) очень эффективны, так как они предоставляют контекстное представление требований системы. Одной из основных причин, почему вам стоит их использовать, является то, что они носят нетехнический характер и предоставляют пошаговое описание взаимодействия актеров (пользователей системы - людей или другие системы) с системой. Простота сценариев является их большим преимуществом.

Часто документы, которые должны содержать полное описание требований к системе, на самом деле содержат лишь деловой регламент и список нужд пользователей. Для того, чтобы проект шел вперед, вам необходимо описать все цели и стремления, и для этого более всего подходят сценарии использования. Они связывают весь процесс разработки - от сбора требований пользователей до тестирования программного обеспечения.

Система управление изменениями

Это нечто иное, чем принцип избегания изменений в вашем проекте. Вместо этого, уделите внимание новым запросам и решайте (c пользователями), каким образом данные изменения могут быть реализованы. К примеру, что следует предпринять, если дата завершения строго оговорена, а вам выдвинуто новое требование? Стоит ли вам в  таком случае опустить реализацию какого-либо другого требования, или же стоит перенести дату выпуска системы?

Визуальное моделирование ("картина стоит 1000 слов")

Визуальное моделирование - это современное название для блок-схем, используемых раньше в производстве ПО. До сих пор визуальная поддержка очень ценится, и диаграммы должны быть использованы на протяжении всего проекта. Вам стоит требовать от всех использование одной определенной системы обозначений, как от бизнес-аналитиков, так и от дизайнеров, программистов и тестеров. UML - универсальный язык моделирования - является де-факто стандартом разработки систем и должен быть использован для постоянного и четкого общения на протяжении всего проекта. Его использование является безоговорочным условием.

Насколько вы фокусируетесь на рисках?

Я работал со многими клиентами, различным высшим руководством и техническими специалистами, которые клялись в том, что они учитывают все риски и следуют итеративному подходу к разработке ПО. И вы, скорее всего, столкнетесь с этим, но  вот как вам узнать,  действительно ли ваша группа ИТ-специалистов  использует  итеративный способ разработки, учитывающий риски?

Вот несколько вопросов, которые помогут вам в этом:

Как долго длится одна итерация?

Правильный ответ - несколько дней либо максимум примерно 4 недели. Ответ «три месяца и более» говорит о том, что процесс до сих пор имеет вид водопадной модели, которая отличается длинными циклами и связана с большим риском пойти по неверному пути, с  большой вероятностью  обнаружения этого факта в самом конце, когда ситуацию практически невозможно исправить.

Что является результатом каждой итерации?

Ответом должна быть демонстрация пользователям  какого- либо рабочего программного обеспечения,  с получением при этом  от них отзывов  и мнений. Если ответом является документ с одобрением, то они не понимают сути метода.

Когда пользователи увидят то, что они должны получить в итоге?

Верным ответом на этот вопрос будет – «в конце каждой (короткой) итерации», а ответ "только во время тестирования перед выпуском" совершенно неприемлем.

Когда вы начнете тестирование интеграции?

Ответом должно быть то, что тестирование интеграции - это продолжительный процесс, который происходит во время каждой итерации.

Как вы управляете рисками?

Должны присутствовать регулярная оценка риска, представленная в виде вероятности и влияния на график разработки, а также предлагаемые стратегии избегания риска. Руководитель проекта должен иметь список возможных рисков, который доступен всех людям, связанным с проектом. Таков примерный ответ на данный вопрос.

Длительная непрерывность бизнес-процессов

Что же получит ваш бизнес в результате использования всего вышеописанного опыта?

Мы знаем, что разработка ПО - это очень рискованный бизнес, который требует много времени, денег и усилий. Но самые большие затраты  следуют по завершении начальной разработки, как это показано на рисунке 6, когда система входит в этап поддержки и пересмотра.

Рис. 6: Структура расходов ПО

Переняв этот опыт и фокусируясь на разработке ПО, предоставляющего клиентам то, что им нужно, можно создавать высококачественные системы, наиболее подходящие бизнесу. Такие системы легче поддерживать и модифицировать, что тем самым может снизить последующие эксплуатационные расходы и вероятность рисков.

Cliff Murphy