• Выгоды от применения итераций в OpenUP/Basic
• Управление рисками

Введение

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

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

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

Practices

Далее описываются подходы (practices), связанные с этим принципом.

Разрабатывайте проект по итерациям

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

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

Итерация должна быть нацелена на достижение очередной контрольной точки

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

Поэтому необходимо делить проект на фазы (Исследование, Развитие, Конструирование, Передача), где каждая фаза имеет четкую управленческую контрольную точку. Цель каждой фазы состоит в достижении этой контрольной точки. 

Работайте с рисками

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

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

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

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

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

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

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

При необходимости документируйте изменения. Для неформальных проектов может быть достаточно обсуждения с заинтересованными лицами.

Объективно измеряйте продвижение проекта

Если вы не имеете объективной информации о продвижении проекта, вы на самом деле не знаете, является ли ваш проект успешным или нет. Неопределенность и постоянные изменения сильно затрудняют объективную оценку продвижения проекта, и участники проекта имеют впечатляющую возможность верить, что все замечательно, перед лицом катастрофы.

Поэтому следует получать четкую картину с помощью объективого измерения прогресса. Лучший способ измерить прогресс - выпустить работающую программу, то есть сделать то, что вы будете делать при использовании эволюционного подхода. Также можно определить набор объективных  метрик, которые вы будете собирать во время итерации (например, количество реализованных и проверенных требований, отношение количества обнаруженных дефектов к количеству исправленных) и анализировать во время оценки итерации. Не полагайтесь только на одну метрику. Используйте набор метрик и отслеживайте тенденции.

Постоянно переоценивайте, что нужно сделать

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

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

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