Как гибкие методы разработки сокращают риски для требований проекта

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

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

Риск 1: Нереалистичные ожидания клиента и излишнее усердие разработчика

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

Как agile решает данные проблемы? В проектах agile мы разбиваем требования к результатам на короткие итерации продолжительностью 1 – 3 недели. Каждый период начинается с совещания по планированию итерации, на котором клиент решает, какая работа должна быть выполнена.

Процесс полностью понятен:

1. Клиент утверждает цель или тему для итерации.
2. Члены группы по реализации сообщают, сколько имеющегося у них времени они могут потратить на работу (т.е., их работоспособность, обычно в рабочих часах).
3. Клиент выбирает первоочередные требования из незавершенной работы (сводный каталог работы, необходимой для создания продукта).
4. Желаемые требования более подробно обсуждаются и конкретизируются по мере необходимости.
5. Группа оценивает задачи для работы.
6. Группа и клиент изучают риски и зависимости.
7. Группа принимает точное решение о том, какие требования будут реализованы.

Мы выяснили, что ключ к данному процессу – это представление каждого элемента работы (также называемые “истории”) в краткой и четко определенной форме. Если вы не знаете заранее критерии завершенности – для определения, выполнено ли требование, – то ожидания клиента могут быть разрушены, или члены группы реализации могут сделать (неверные) предположения и добавить дополнительные функции.

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

Риск 2: Недостаточное участие клиента

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

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

Неважно, кто берет на себя роль клиента, он является передним краем и ядром гибкого проекта.

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

Риск 3: Плохой анализ последствий

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

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

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

Риск 4: Расползание масштаба проекта

Неконтролируемое расширение требований в течение проекта – это самый высокий риск любого программного проекта. К тому же, чем больше продукт, тем больше растут требования. Хотя расползание масштаба фактически можно рассматривать как норму.

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

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

Можно добавлять новые элементы или истории в список невыполненных работ по мере их появления. Гибкие группы управляют расползанием масштаба путем постоянного сокращения списка невыполненных работ.

Масштаб проекта определяется на высоком уровне, но это не юридически обязательный договор. Работая во время кратких циклов реализации над маленькой подгруппой требований, гибкие группы могут лучше контролировать масштаб. Каждые 1-3 месяца они проводят планирование выпуска (версии), чтобы адаптировать план реализации требований к более долгому временному интервалу.

Риск 5: Ошибочные требования

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

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

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

Риск 6: Новые процессы и инструменты

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

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

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

Сокращение реальных рисков

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