Очень сильно связана с Автоматы в аналитике, есть много пересекающихся идей, которые, вероятно, стоит вынести в самостоятельные заметки.
- Цель команды разработки - создание воплощения системы для удовлетворения нужд потребителей / реализации возможностей.
- Воплощение системы в случае разработки ПО - это комплексная штука. Включает в себя как минимум среду исполнения и набор исполняемых инструкций. Воплощение системы существует, когда набор инструкций выполняется в определенной среде исполнения. Возможно, включает в себя также и сторонние средства для доступа к результатам выполнения инструкций (браузеры, терминалы, принтеры для печати?). Конкретный пример - скомпилированный и скомпонованный в бинарник java-код, который запущен на выполнение в конкретной реализации java-машины на конкретном экземпляре виртуальной машины в некотором сетевом окружении.
- Техническая сложность воплощения системы - это еще не вся сложность. Еще существует как минимум сложность моделируемой предметной области.
- Совокупность сложностей дает в итоге настолько комплексную и объемную систему, что ни один человек не в состоянии удержать ее в голове и эффективно разрабатывать / развивать. Поэтому необходимо собрать команду разработки, включающую специалистов в разных функциональных областях.
- Никто в команде разработки не способен создать собственно воплощение системы, потому что это run-time штука, это электронные разряды / импульсы в сетях и на серверах в дата-центрах. Никто не в состоянии манипулировать атомами и электронами во время выполнения.
- Поэтому все, что делает “человеческая” часть команды разработки, - это составление описаний целевой системы. На основании этих описаний затем специальные инструменты подготовят и запустят на выполнение воплощение системы.
Вот это большой вопрос насчет описаний. Действительно ли мы только и делаем, что создаем описания? Точнее, только ли описания мы создаем? Скорее всего, ответ "нет", в понятие "Рабочий продукт" могут входить и какие-нибудь другие артефакты, над этим нужно поразмыслить.
- Описания и модели создаются для выявления и удовлетворения разных ролевых интересов. При этом можно рассматривать интересы внешних проектных ролей как первичные - именно из-за этих интересов и начался проект. А вот интересы внутренних проектных ролей - вторичные, они появляются из-за того, что мы не можем явно, непосредственно и быстро удовлетворить первичные потребности. Приходится организовывать проектную деятельность, в ходе которой у участников возникают свои неудовлетворенности и интересы.
- Любой Рабочий продукт призван удовлетворить какой-либо Ролевой интерес. Если мы не можем выявить Ролевой интерес для созданного Рабочего продукта, значит, продукт был создан зря, он никому не нужен. Практика, приведшая к созданию продукта, выходит, тоже была пустой тратой времени.
- Более того, практики, не создающие рабочие продукты, выходит, тоже не нужны, так как не удовлетворяют никакие ролевые интересы. К тому же они не относятся ни к одной из ролей, так как роль - это совокупность практик, нацеленных на создание рабочих продуктов.
- Из последних двух пунктов следует, что команде нужно избавляться от “пустых” рабочих продуктов и практик. Для каждого рабочего продукта следует найти роль и интерес, для выявления или удовлетворения которого продукт был создан. Если роль и/или интерес не найден, от рабочего продукта нужно отказаться. Каждая практика, не создающая продукт, должна быть пересмотрена и либо перестроена так, чтобы создавать рабочий продукт, либо прекращена.