Пытался уместить в голове все инсайты и мысли, что возникли после прочтения “Сначала найти целевую систему” (Глава 9. Секция 1). Получилось плотно. Вот два момента, которые привели к метанойе (я серьезно не знаю, как я раньше мог думать иначе, это же очевидно):
Целевую систему вы должны всё-таки угадать, а не «вычислить по формуле», «вывести по алгоритму». Дальше эту догадку надо прокритиковать, попытаться улучшить, если она оказалась хуже других догадок, и в итоге выбрать лучшую из имеющихся (поэтому обычно делают много догадок, и только выжившую критику принимают всерьёз, то есть кладут в основу проекта создания системы).
Ожидаемое поведение системы — это предсказание того, что должно бы произойти при эксплуатации. В случае требований раньше говорили поэтому о функциональных требованиях (деонтика), а сейчас это просто гипотезы о функциональности (докса), поэтому нет «должна»,только «должна бы» (а жизнь потом покажет, оправдалась ли гипотеза).
- Сценарий использования - это гипотеза о функциональности.
- Гипотезы - это то, что “должно бы” быть (и в принципе, и каким то), но не обязано. Это догадка/предположение, требующее подтверждения. Автор гипотезы не “знает”, он “предполагает”. Если выделить метод работы с гипотезами аналогично старому “управление требованями”, то я бы сказал, что главная цель этого метода “угадать с минимальными издержками”.
- Гипотезы крутятся в итерационном процессе: выдвини гипотезу, покритикуй, проверь на реализуемость/непротиворечивость с другими гипотезами, утряси ее с другими гипотезами/поторгуйся, утверди. Здесь есть какие то “промежуточные этапы”, когда прошедшие этот путь гипотезы становятся требованиями (здесь требование в смысле задачи для исполнителя “делай так”). В своей голове я сейчас именно так их разделяю, требование - это утвержденная гипотеза (прибитая гвоздями, ведь в методе работы неизбежно будет этап утверждения и непересмотра, например, когда требование уже в спринте и/или разработке и “откатывать” гипотезу может дороже, чем реализовывать).
- Гипотеза о функциональности/Сценарий использования - это предмет торгов. Торгуются роли. Гипотеза не доказывается (аналогия из любой науки), а уторговывается. Потому что цель торгов не понять, кто прав (или наиболее вероятно прав), а привести к балансу интересов.
- Результат торгов - договоренность. Так что любая гипотеза будет еще предметом договоренностей (некто: если мы принимаем этот сценарий, то давай в другом будет по моему).
- Договоренности временны, они могут и будут пересматриваться. Пересмотр одного сценария может привести к пересмотру другого и это нормально.
- (Хм, а какой тип у договоренности? Как будто это ментальный объект, зафиксированный в документе::описание. Или, стоп, может это работа? Торги::процесс, договариваться/торговаться::метод, договоренность::работа)
Связь с целевой системой:
- Целевая система - это система, о которой нужно со всеми договориться.
- Целевая система - это первый ход в графе создания (рекурсия).
- Целевая система - это система, которая “угадывается”/воображается и далее уторговывается, а не “вычисляется по формуле” и не “выводится по алгоритму”.
- Целевая система - это система, которую “выявляют”/discover/находят в ходе стратегирования.
- Целевая система в момент проектирования - это система, которая проектируется на основе гипотез об ее успешности.
Кроме описанных тезисов есть еще неочевидный инкремент в мою психику, она стала сильно спокойнее относиться к пересмотру требований, а я на данный момент думаю, как мне использовать это знание в своей деятельности.