David Barnholdt написал статью "An exercise based on my PSL experience:The power of open-ended requirements" (упражнение на основе моего опыта в PSL: Сила открытых требований).

Сегодня я провёл занятие по Scrum и Lean. Я смог опробовать часть материалов из курса PSL в упражнениях, которые разработал всего за день до занятия.

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

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

Одна из групп получила следующее требование:

Нарисовать красивый летний луг с синими и красными цветами на зеленой траве, коровами и птицами под ярким солнцем.

Другая группа получила следующее требование:

Нарисуйте прекрасный летний луг с:

• 10 синими цветами с 5 лепестками каждый
• 5 синими цветами с 6 лепестками каждый
• 13 красными цветами с 6 лепестками каждый
• 2 коровами с 3 черными пятнами

• 1 коровой с 5 черными пятнами
• 2 коровами с 4 черными пятнами
• 2 птицами, которые будут жить в верхнем левом углу
• 3 птицами в середине
• одним солнцем справа с 5 солнечными лучами

Прежде чем читать дальше, посмотрите на эти рисунки здесь и угадайте, какой рисунок был сделан какой группой:

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

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

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

Узнаёте ситуацию из мира разработки ПО? Я точно узнаю. И я хорошо помню, как это было утомительно — реализовывать избыточно детализированные требования. Мне просто хотелось поскорее с этим покончить.

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

Я почувствовал, что класс получил тот же «АХ-опыт», что и я сам на классе PSL.

Что такое PSL?

PSL в данном случае расшифровывается как Problem Statement Language - язык для четкого описания проблем в IT-проектах.

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

Автор обсуждает, как PSL (в сочетании с другими методами, например, Goal Question Metric – GQM) применяется для:

• Анализа корневых причин проблем в проектах.
• Формализации нечетких требований.
• Улучшения коммуникации между заказчиками и разработчиками.

Почему это важно?

PSL превращает расплывчатые жалобы (типа «система работает медленно») в конкретные, измеримые утверждения, например:

 

При нагрузке >1000 пользователей время отклика системы превышает 2 секунды в 90% случаев.

 

Аналоги PSL:

Похожие инструменты – DSL (Domain-Specific Language) или UML для моделирования, но PSL фокусируется именно на проблемах, а не на решениях.

Примечание: Аббревиатура PSL редко встречается в современной литературе – сейчас чаще используют более универсальные методы, например, User Stories или Jobs to be Done). Статья Дэвида от 2009 года отражает «ретро-подход» к инженерии требований 😊.