TGTGInsightаналитика telegramLIVE / telegram public index
← Системный сдвиг
Системный сдвиг avatar

TGINSIGHT POST

Post #469

@systemswing

Системный сдвиг

Просмотры4,000Количество просмотров
Опубликован11 сент.11.09.2024, 11:59
Содержимое поста

Содержимое

Ну всё, можно считать себя экспертом: Карл Вигерс говорит от требованиях то же и теми же словами, что и я (https://t.me/systemswing/450), правда, чуть раньше — в 2021 году: Люди часто говорят о сборе требований к программному проекту, но это создает неверное впечатление. Слово «сбор» предполагает, что требования уже лежат где-то в готовом виде и только и ждут, чтобы их подобрали. Когда я слышу, как кто-то говорит «сбор требований», в моем воображении всплывает картинка сбора цветов или охоты за пасхальными яйцами. Увы, это не так просто. Требования редко существуют в сознании пользователей в полностью сформированном виде, готовом для передачи бизнес-аналитику или команде разработки, только спроси. Создание набора требований определенно подразумевает этап сбора некой информации, но также включает открытие и изобретение(курсив мой. Смотрите, даже Вигерс пишет, что мы изобретаем требования!). Термин «выявление требований» (requirements elicitation) точнее описывает, как люди из ИТ сотрудничают с заинтересованными сторонами, чтобы изучить, как те работают сейчас, и определить, какие возможности должна предоставлять будущая программная система. Согласно словарю The American Heritage Dictionary of the English Language (2020), под словом elicitation подразумевается выманивание, вытягивание или провоцирование. Слова «выманивание» и «вытягивание» точнее описывают процесс, чем слова выявление или сбор. Самые бесполезные вопросы, которые не следует задавать при изучении требований: «Чего вы хотите?» и «Каковы ваши требования?». Такие расплывчатые вопросы вызывают поток множества случайных — но важных, конечно — сведений, смешанных с посторонней информацией и приправленных невысказанными предположениями. Бизнес-аналитик не просто записывает все, что ему говорят заинтересованные стороны. Опытный БА фасилитирует обсуждение, направляя участников на раскрытие имеющего отношение к проблеме знания в структурированном виде. Далее он пишет, что с первого раза всё узнать не получится, что нужно вернуться к стейкхолдерам, преодолеть их "Ну мы же это уже обсуждали!", но без этого никак. Выявление требований, — пишет Вигерс, — это как очистка луковицы, только наоборот: чем больше слоев счищаешь, тем больше она становится. Это из последней книги Вигерса: Software Development Pearls: Lessons from Fifty Years of Software Experience ("Жемчужины разработки: Чему мы научились за 50 лет создания ПО") Книга, кажется, небезынтересная, придётся читать. Приведенная цитата — это Урок 11, а дальше он пишет, что Две основные практики выявления требований — телепатия и ясновидение. Они не работают. (Урок 13) Большая группа людей не способна организованно покинуть горящую комнату, не говоря уж о том, чтобы коллективно сформулировать какое-то требование (Урок 14) И что идеальный вариант — когда разработчик один, пользователь один, они сидят за соседними столами, и пользователю можно сразу показать готовый результат. Тогда и требования не нужны. И к этой идеальной картине нужно стремиться — что я готов подтвердить, это и правда самый лучший способ! В общем, любопытно. Напишу больше, как дочитаю 📕