Введение

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

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

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

Задача всех участников проекта состоит в создании решения, имеющего максимальную ценность для заинтересованных лиц, при учете всех ограничений. Balance is about making the critical, cost-benefit trade-offs between desired features and the subsequent design decisions that define the architecture of the system.

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

Практические рекомендации

Знайте аудиторию

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

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

Отделите проблему от решения

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

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

Создайте общее понимание прикладной области

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

Enhance and share all parties’ understandings of the domain. A concise and shared understanding of the problem domain enhances communication and project effectiveness. Start by defining the problem in the Vision document. As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent, shared use of the language of the domain.

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

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

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

Установите и сохраняйте согласие относительно приоритетов

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

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

Находите компромиссы, увеличивающие ценность системы

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

Расстановку приоритетов требований и разработку возможных вариантов архитектуры осуществляйте в совместной работе членов команды и заинтересованных лиц. Для оценки стоимости реализации тех или иных ценных свойств системы используйте различные варианты архитектуры. Candidate solutions are considered at a high level when determining architectural feasibility. Different architectural perspectives can result in different assessments of cost versus benefit. Вариант архитектуры, который предоставляет наиболее полное покрытие необходимых свойств системы при меньшей стоимости и выбирается для использования в решении.

Следите за масштабом проекта

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

Manage change while maintaining agreements with the stakeholders. Modern processes always manage change, continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making trade-offs, and re-prioritizing work. Ожидания заинтересованных лиц и разработчиков должны быть реальны и привязаны к циклу разработки.

Знайте, когда нужно остановиться

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

Как только достигнуто желаемое качество - прекратите разработку. Помните, что "Качество есть соответствие требованиям" [CRO79]. На практике качество - это то, что дает чувство завершенности. Система готова к приемке заинтересованными лицами, как только реализованы и проверены основные требования.